Su sitio es lento, ¿y GTMetrix muestra más de 130 peticiones HTTP por página?

No se trata de una cifra abstracta de un informe. Cada petición es una llamada del navegador al servidor para solicitar un archivo: un script, una hoja de estilo, una imagen o una fuente. Cuantas más peticiones haya, más tiempo pasan los visitantes mirando una pantalla en blanco. Según Portent, un retraso en la carga de 0 a 3 segundos reduce la conversión un 2,5%. Y cada segundo adicional a partir de ahí cuesta otro 4,4%.

El problema con las peticiones HTTP no es que existan. Es que la mayoría de los sitios en WordPress generan muchas más de las necesarias. A continuación, cinco pasos concretos que reducen la cantidad de peticiones sin necesidad de reescribir su sitio desde cero.

💡 Resumen rápido:

• Elimine plugins y temas no utilizados que generan peticiones extra en cada página
• Optimice imágenes: comprima archivos, elimine imágenes no usadas, combine iconos en sprites
• Combine CSS y JavaScript en 1 o 2 archivos y active la minificación
• Configure la carga diferida para los scripts que bloquean la renderización de la página
• Active la caché y una CDN para que los visitantes recurrentes no recarguen todo el sitio

Paso 1. Elimine lo que sobra

Cada plugin instalado trae consigo archivos. PHP, CSS, JavaScript: cualquiera de ellos genera una petición HTTP cuando la página se carga. Veinte plugins significan casi un centenar de peticiones solo en el arranque, antes de que aparezca el contenido.

Lo primero que debe hacer es una auditoría. Abra Plugins → Plugins instalados y pregúntese con sinceridad: ¿cuáles son críticos para el funcionamiento del sitio y cuáles están ahí «por si acaso»? Ese analizador SEO que instaló hace un año y abrió dos veces es candidato a ser eliminado. El plugin de iconos sociales también lo es, si ya ha añadido los enlaces en el pie de página de todos modos.

Una categoría aparte son los plugins que se conectan a servidores de terceros. Chat en vivo, radio en streaming, notificaciones push. Cada uno de estos plugins crea peticiones HTTP externas adicionales a servidores de terceros. Elimine todo aquello sin lo que el sitio pueda funcionar. ¿Lo necesita una vez al mes? Instálelo por un día y luego elimínelo.

La misma regla se aplica a los temas. En Apariencia → Temas, conserve solo su tema activo y uno de respaldo (por ejemplo, el tema predeterminado Twenty Twenty-Five). Elimine el resto.

Si necesita un plugin pero solo en una página específica, cárguelo de forma selectiva. Asset CleanUp: Page Speed Booster hace exactamente esto. Es un plugin gratuito con más de 100 000 instalaciones activas y una valoración de 4,7 en WordPress.org.

El plugin analiza la página, muestra una lista de los archivos CSS y JS cargados y le permite desactivar archivos específicos en páginas concretas, tipos de contenido o en todo el sitio. ¿Necesita Contact Form 7 solo en la página de contacto? Desmárquelo en el resto, y sus scripts no se cargarán donde no se use el formulario.

🔗 Asset CleanUp en WordPress.org

De paso, optimice su base de datos. Después de limpiar los plugins, sus configuraciones y registros permanecen en las tablas y también deberían eliminarse. Revise también los enlaces rotos: cada redirección es una petición HTTP extra.

Para ver con claridad la magnitud del problema antes y después, pruebe su sitio en GTMetrix:

La primera ejecución muestra la línea base: número de peticiones, tamaño total de la página, tiempo de carga. Después de cada paso de este artículo, vuelva a ejecutar la prueba. Así verá qué cambios tuvieron el mayor impacto.

Paso 2. Optimice las imágenes

Las imágenes son el mayor «peso» en una página promedio de WordPress. Según HTTP Archive, las imágenes representan alrededor del 44% del tamaño total de la página en equipos de escritorio. Y cada imagen es una petición HTTP.

Empiece por eliminar los archivos no utilizados. En Medios → Biblioteca, filtre por «Sin adjuntar». Son imágenes no vinculadas a ninguna entrada. Si no se usan en el tema ni en el pie de página, elimínelas.

A continuación, la compresión. Plugins como WP Compress se encargan de esto automáticamente: al subir una imagen, esta pasa por un optimizador en la nube, se comprime sin pérdida visible de calidad y se convierte a WebP o AVIF. Estos formatos son notablemente más ligeros que JPEG con la misma calidad visual. Según Google, WebP reduce el tamaño del archivo en un promedio del 25 al 35% en comparación con JPEG.

WP Compress tiene más de 10 000 instalaciones activas, una valoración de 4,5 sobre 5 y más de 1,1 millones de descargas en WordPress.org. Las primeras 100 imágenes son gratuitas, suficientes para notar la diferencia.

🔗 WP Compress en WordPress.org

La compresión por sí sola no reduce el número de peticiones HTTP. Pero sí reduce el tamaño de cada archivo, lo que implica menos tiempo para transferirlo. Combinado con los demás pasos, esto proporciona un aumento de velocidad notable.

Sprites CSS: un archivo en lugar de diez

Si tiene una docena de iconos pequeños en una página (redes sociales, flechas, estrellas de valoración), cada uno se carga como una petición separada. Un sprite CSS lo resuelve: todos los iconos se combinan en un solo archivo, y el CSS muestra el fragmento necesario.

Funciona así: cinco imágenes significan cinco peticiones al servidor. Esas mismas cinco imágenes combinadas en un solo sprite significan una petición. Herramientas en línea como CSS Sprite Generator pueden crear sprites por usted. Se requieren conocimientos básicos de CSS para establecer el background-position de cada icono.

Nota: si su servidor admite HTTP/2, los archivos se cargan de forma asíncrona dentro de una única conexión. En ese caso, el ahorro del sprite es menos perceptible. Pero en la práctica, una docena de iconos en un solo archivo sigue cargando más rápido que diez archivos separados.

Paso 3. Combine y minifique CSS y JavaScript

Un sitio típico de WordPress tiene más de 40 archivos JS y más de 20 archivos CSS. Cada uno es una petición HTTP separada. Eso suma más de 60 llamadas al servidor solo para scripts y estilos, todos cargándose antes de que aparezca el contenido.

La minificación elimina todo lo innecesario de los archivos: espacios, saltos de línea, comentarios. El archivo se vuelve más ligero, pero el número de peticiones HTTP sigue igual.

La combinación fusiona varios archivos en uno. Cinco archivos CSS se convierten en dos (uno para el contenido visible sin desplazamiento, otro para el resto). Cinco archivos JS, lo mismo. Y en lugar de diez peticiones, se queda en dos o tres.

La herramienta gratuita más popular para esto es Autoptimize. Un plugin con un millón de instalaciones activas y una valoración de 4,7. En los ajustes, hay tres casillas de verificación: optimizar HTML, CSS y JS. Marque las tres y vea los resultados inmediatos.

Para un control más preciso, existe WP Rocket, una solución premium que combina archivos, los minifica y añade caché en una sola interfaz.

Después de combinar, verifique siempre su sitio en modo incógnito: a veces, fusionar archivos rompe la maquetación. Si algo se ve mal, desactive la combinación para el archivo problemático y conserve solo la minificación.

🔗 Sitio oficial de WP Rocket

Un detalle más: combinar archivos no es una solución universal. Si un plugin carga scripts externos desde una CDN (Google Fonts, reCAPTCHA, reproductor de YouTube), no puede combinarlos. Solo puede diferirlos o cargarlos de forma asíncrona, lo cual nos lleva al siguiente paso.

Paso 4. Gestione los scripts que bloquean el renderizado

El navegador lee una página de arriba hacia abajo. Cuando encuentra <script src="..."> en el <head>, detiene el renderizado, descarga completamente el script y solo entonces continúa. Durante ese tiempo, los visitantes ven una página en blanco.

La solución es mover los scripts que no son necesarios para mostrar la primera pantalla al final de la página, o añadir el atributo async/defer. La diferencia:

• defer: el script se carga en segundo plano, pero se ejecuta estrictamente después de que el análisis del HTML termine y en el orden en que se incluyeron;
• async: el script se carga y se ejecuta en la primera oportunidad, sin un orden garantizado.

Para WordPress, existe un plugin gratuito llamado Async JavaScript. Añade async o defer a scripts seleccionados mediante una interfaz clara. Funciona nada más instalarlo, pero requiere precaución: si un script añadido con async necesita ejecutarse antes que otro, la página puede romperse.

Un enfoque seguro es probar con un script, revisar el sitio en modo incógnito y luego pasar al siguiente.

WP Rocket también puede diferir scripts: vaya a Optimización de archivos → Cargar JavaScript diferido. Seleccione «Diferido» y añada jQuery a las exclusiones, ya que la mayoría de los temas y plugins de WordPress dependen de él.

Resultado: la página comienza a renderizarse antes, incluso si el número total de solicitudes HTTP no ha cambiado. Los visitantes ven el contenido mientras los scripts restantes se cargan en segundo plano.

Paso 5. Active el caché y un CDN

El caché reduce directamente las solicitudes HTTP en visitas repetidas. La mecánica es simple: el navegador guarda localmente los archivos estáticos (CSS, JS, imágenes, fuentes). En la siguiente carga de la página, en lugar de solicitarlos al servidor, los obtiene del caché. Cero solicitudes HTTP para ese archivo.

El caché del lado del servidor es el siguiente nivel: el servidor entrega una página HTML ya ensamblada en lugar de ejecutar decenas de consultas PHP a la base de datos. Los plugins de caché (WP Rocket, Flying Press, W3 Total Cache) hacen esto automáticamente.

Un CDN (Content Delivery Network, red de distribución de contenidos) es una red de servidores en todo el mundo. En lugar de extraer los archivos de su hosting en los Países Bajos para un visitante en Brasil, el CDN los entrega desde el nodo más cercano. Además, los proveedores de CDN suelen incluir compresión, minificación y optimización de imágenes de serie.

Cloudflare es una opción gratuita que cubre las necesidades básicas: CDN, protección DDoS, SSL gratuito.

Instale el plugin de Cloudflare para WordPress. Conecta su sitio al CDN y proporciona ajustes básicos directamente desde el panel de administración. Para un control más preciso, acceda al panel de Cloudflare: active la Minificación automática para CSS/JS/HTML, la compresión Brotli y Rocket Loader para la carga asíncrona de scripts.

🔗 Cloudflare en WordPress.org

Con el caché y el CDN, el número de solicitudes HTTP para los visitantes recurrentes se reduce drásticamente. Primera visita: carga completa. Segunda visita: la mayoría de los archivos provienen del caché del navegador y del nodo CDN más cercano, sin ninguna llamada a su servidor.

Extra: compruebe si su servidor admite HTTP/2

HTTP/2 es un protocolo que transfiere múltiples archivos a través de una única conexión TCP. El navegador no espera a que el archivo n.º 1 termine de descargarse antes de solicitar el archivo n.º 2; se cargan en paralelo. Esto reduce el impacto de un alto número de solicitudes HTTP: 60 archivos sobre HTTP/2 cargan más rápido que esos mismos 60 sobre HTTP/1.1.

Compruebe su servidor usando la herramienta de prueba HTTP/2 de KeyCDN. Introduzca su dominio y haga clic en «Test». Un resultado de «HTTP/2 is supported» significa que la multiplexación está funcionando.

Si la prueba muestra HTTP/1.1, contacte con su proveedor de hosting. La mayoría de los proveedores de hosting modernos (SiteGround, Cloudways, Kinsta) habilitan HTTP/2 por defecto. En un hosting compartido de la década de 2010, puede que no sea el caso. Compruebe también su versión de PHP: actualizar a una versión moderna de PHP proporciona una mejora de rendimiento notable, mientras que las versiones obsoletas procesan las solicitudes significativamente más lento. Si su proveedor no actualiza ni el protocolo ni la versión de PHP, quizás sea momento de considerar cambiar de proveedor.

Si prefiere el formato en video, aquí tiene una guía visual para reducir las solicitudes HTTP en WordPress (12 minutos).

⁉️🤔 Preguntas frecuentes

¿Cuántas solicitudes HTTP se consideran normales para WordPress?

Un rango objetivo es de 30 a 60 por página. Cualquier cifra por encima de 80-90 requiere optimización. GTMetrix y Pingdom muestran números específicos en sus informes. Después de aplicar los cinco pasos de este artículo, es realista bajar de 130 a 35-45 solicitudes.

«Tengo un sitio en Elementor, y ya tiene más de 100 solicitudes. ¿Es eso normal?»

Los maquetadores visuales generan mucho CSS y JS por naturaleza. Elementor y Divi añaden 30-50 solicitudes por sí solos. Esto no significa «acéptelo»; significa que el resto de su sitio debe estar lo más limpio posible. Elimine todo lo que no esté relacionado con el maquetador: plugins innecesarios, fuentes externas, imágenes no optimizadas. Conserve solo lo que realmente sirva a sus visitantes.

¿Qué importa más: el número de solicitudes o el tamaño total de la página?

Ambos. 20 solicitudes de 1 MB cada una significan una carga de página de 20 segundos. 100 solicitudes de 5 KB cada una podrían cargar más rápido, pero cada solicitud conlleva una sobrecarga por la búsqueda DNS, la conexión TCP y el handshake TLS. En HTTP/2, esta diferencia se suaviza. En HTTP/1.1, es crítica. Optimice ambos: reduzca el número de solicitudes mediante la combinación de archivos y sprites, reduzca el tamaño mediante compresión y minificación.

¿Puedo arreglármelas sin plugins?

Parcialmente, sí. La minificación de CSS/JS se puede configurar mediante Gulp o Webpack durante el desarrollo del tema. HTTP/2 se habilita a nivel de servidor (configuración de Nginx/Apache). El caché se puede gestionar mediante reglas del servidor. Pero para la mayoría de los propietarios de sitios WordPress, los plugins son la vía más práctica: la configuración lleva minutos, los resultados son inmediatos y el riesgo de romper el sitio es menor.

¿Con qué frecuencia debo volver a comprobar el número de solicitudes HTTP?

Después de cada instalación o actualización importante de un plugin. Un plugin nuevo podría añadir su CSS/JS a todas las páginas, y usted no lo notará hasta que el sitio empiece a ralentizarse. Una vez al mes es suficiente para las comprobaciones rutinarias. GTMetrix le permite configurar un monitoreo automático con alertas cuando el rendimiento disminuye.

¿Necesito esta guía si ya tengo un hosting rápido?

El hosting resuelve parte del problema a nivel de servidor, pero no a nivel de código. Si un plugin inserta 15 scripts en el <head> de la página, ni siquiera los servidores de primer nivel harán que se carguen al instante. El navegador seguirá esperando. Un hosting rápido le da una ventaja inicial, pero el verdadero ganador es quien también limpia el lado del cliente.

¿Qué reduce realmente las peticiones HTTP y qué no?

Repasemos todos los pasos sin ilusiones:

• Limpiar plugins y temas produce la mejora más notable. Cada plugin eliminado suprime su CSS, JS y llamadas externas. En la práctica, desaparecen entre 10 y 30 peticiones tras una auditoría.
• La compresión de imágenes reduce el tamaño de los archivos, pero el número de peticiones sigue igual. Sin embargo, el tiempo total de carga disminuye de forma apreciable.
• Combinar CSS y JS reduce significativamente el número de peticiones. Inconveniente: puede romper la maquetación, así que verifique después de cada cambio.
• Carga diferida de scripts: mismo número de peticiones, pero la página se vuelve visible antes.
• Caché y CDN: para los visitantes nuevos, la diferencia es mínima. Para los visitantes recurrentes, las cargas repetidas de página ocurren sin una sola petición al servidor.

Si tuviéramos que elegir exactamente tres acciones que generan el mayor impacto en un sitio WordPress típico: (1) eliminar los plugins innecesarios, (2) activar la combinación de CSS/JS mediante Autoptimize, (3) configurar Cloudflare. Son tres pasos que llevan una tarde en lugar de una semana, y verá los resultados en las cifras de GTMetrix al día siguiente.