Reducir las peticiones HTTP de WordPress: Cómo optimizar la velocidad de su sitio web

Las peticiones HTTP de WordPress determinan la rapidez con la que aparecen tus páginas porque cada petición de CSS, JS, imágenes o fuentes lleva su tiempo. Te mostraré cómo reducir el número de peticiones, evitar el bloqueo de renderizado y optimizar el sitio web inmediatamente perceptible acelere.

Puntos centrales

Los siguientes puntos centrales le conducirán rápidamente a un menor número de consultas y a un mejor LCP con estable Función:

• Almacenamiento en caché uso: La caché de navegador, páginas y objetos reduce significativamente las peticiones repetidas.
• CSS/JS optimizar: Minificar, empaquetar, integrar CSS crítico, evitar el bloqueo de renderizado.
• fotos modernizar: WebP/AVIF, lazy loading, dimensiones fijas, sin hero sliders.
• Guiones delay: aplazamiento/retraso para análisis, píxeles, recursos externos.
• CDN/Hosting elegir: HTTP/3, edge caching, TTFB corto para usuarios globales.

¿Qué son las peticiones HTTP en WordPress?

Cada recurso de la página genera su propia petición, es decir, archivos CSS, JavaScript, imágenes, iconos e Fuentes. Los temas y plugins modernos añaden rápidamente muchos archivos pequeños, lo que aumenta el número de Consultas unidades. Cada solicitud implica una búsqueda DNS, un intercambio TCP y una transferencia, y es precisamente esta sobrecarga la que se acumula. Sin optimización, a menudo veo más de 70 peticiones por página, lo que retrasa notablemente la visualización. Los valores objetivo son claramente inferiores: menos de 50 es bueno, menos de 25 es excelente para la máxima velocidad. Una pequeña reducción por tipo de página tiene un amplio impacto porque las plantillas, encabezados y pies de página se cargan en todas partes.

Por qué cada consulta cuenta

Cualquier archivo adicional puede bloquear el renderizado, especialmente los cargados de forma sincrónica CSS y JavaScript. Si estos recursos siguen bloqueando la renderización en la cabecera de la página, los usuarios esperan espacios en blanco y rebotan. Esto tiene un impacto en Core Web Vitals: LCP se retrasa, TBT crece y CLS aumenta sin medidas fijas para imágenes o anuncios. Por eso compruebo constantemente qué recursos son realmente críticos y cuáles puedo retrasar. Si no estás seguro de por qué se ralentizan las peticiones a pesar del pequeño tamaño de los archivos, lee mi guía Por qué bloquear las peticiones HTTP para obtener explicaciones prácticas.

Inicio rápido: medidas con mayor efecto multiplicador

Empiezo con el almacenamiento en caché, la minificación y el lazy loading porque estos pasos producen grandes efectos y pueden implementarse rápidamente. son. Un buen plugin de caché crea páginas HTML estáticas y guarda el Base de datos. La minificación elimina espacios y comentarios, combina archivos y reduce significativamente las descargas. Lazy Loading desplaza las imágenes fuera de pantalla a la parte posterior, lo que ayuda a First Paint y LCP. Con unos pocos clics se pueden conseguir mejoras directas sin cambiar el tema.

Medida de optimización	Solicitudes de reducción	Herramientas/plugins
Almacenamiento en caché (navegador, página, objeto)	50-80% para visitas de ida y vuelta	WP Rocket, Caché LiteSpeed, W3TC
Reducir y combinar	20-50% menos transferencias	Autoptimise, Perfmatters
Imágenes de carga perezosa	30-60% inicial	WP Rocket, función principal
CDN con HTTP/2/3	a 40% más eficiente	Cloudflare, QUIC.cloud

Uso inteligente de la caché

Primero activo la caché del navegador para que los usuarios que vuelven puedan guardar los activos localmente desde el Cache y no otra vez del Servidor carga. La caché de páginas genera HTML estático para los visitantes y ahorra la ejecución de PHP y las consultas a la base de datos. Con el almacenamiento en caché de objetos (por ejemplo, Redis), las consultas frecuentes permanecen en memoria, lo que reduce la carga de las páginas de administración y tienda. Además, Gzip/Brotli reduce la transferencia, lo que reduce el tiempo de transferencia y el volumen de datos. A continuación, compruebo los tiempos de caducidad (control de caché, caduca) y si las cadenas de consulta excluyen innecesariamente de la caché los scripts de marketing.

CSS y JavaScript: Minificar, combinar, cargar

Muchos archivos pequeños significan muchos Solicitudes, Por eso resumo lo menos posible los estilos y los guiones. Paquetes juntos. La minificación reduce el tamaño, pero lo más importante es que haya menos archivos para la ruta crítica. Incluyo el CSS crítico en línea para que el contenido de la mitad superior de la página tenga estilo inmediatamente. Los estilos no críticos se cargan de forma asíncrona o mediante atributos multimedia. Configuro JavaScript para que se aplace o retrase, pero pruebo la secuencia para que no se rompan las dependencias.

Imágenes y soportes: un gran ahorro

Las imágenes suelen causar la mayor proporción de Consultas, por lo tanto convierto a WebP o AVIF y defino fijo Dimensiones. La carga perezosa retrasa las imágenes fuera de pantalla, pero yo precargo la imagen héroe específicamente para un LCP rápido. Responsive srcset asegura que los dispositivos móviles carguen pequeñas variantes. Evito los controles deslizantes en el héroe porque generan muchos archivos y repintados. También utilizo formatos modernos específicos para reducir al mínimo los artefactos.

Fuentes, proveedores externos y scripts externos

Cargo fuentes externas localmente para tener un control total sobre Almacenamiento en caché y Precarga tengo. Combino los estilos de fuente con moderación, a menudo basta con regular y negrita con fuentes variables. Para las analíticas, los gestores de etiquetas y los píxeles, establezco retrasos hasta después de la primera interacción o sólo los cargo después del evento onload. Esto mantiene la ruta crítica libre de archivos innecesarios. También reviso los widgets de las redes sociales y los sustituyo por vistas previas estáticas que recargo al hacer clic.

Elegir bien la CDN y el alojamiento

Una CDN acerca los activos a los usuarios y reduce la latencia y el número de Viajes de ida y vuelta notable en la primera llamada. HTTP/2/3 permite la multiplexación, la priorización y unos apretones de manos TLS más rápidos. El almacenamiento en caché Edge de HTML hace que los grupos de destino internacionales en particular sean más rápidos. En el servidor, presto atención al almacenamiento NVMe, a las versiones actuales de PHP y a los TTFB cortos. Los buenos hosters ofrecen herramientas como Brotli, Early Hints y QUIC, que utilizo activamente.

Casos especiales: REST-API y Admin-Ajax

Muchas instalaciones generan peticiones en segundo plano a través del API REST o admin-ajax.php, por ejemplo para formularios, búsqueda o dinámica Widgets. Identifico estas llamadas en la pestaña de red y compruebo si se pueden reducir los intervalos de sondeo o resumir las peticiones. Cuando es posible, almaceno en caché las respuestas de la API en el servidor y establezco límites de velocidad. Para más información sobre optimizaciones, consulta mi guía sobre Rendimiento de REST-API, que muestra frenos y soluciones típicas. Así es como reduzco las consultas repetidas en segundo plano sin perder funciones.

Medición y control de la velocidad sostenida

Pruebo cada cambio con PageSpeed Insights, Lighthouse y GTmetrix para obtener la información real. Efecto ver y no Regresiones captura. Objetivos: menos de 50 peticiones por página, LCP inferior a 2,5 s, TBT inferior a 200 ms y CLS inferior a 0,1. También miro el gráfico de cascada para visualizar los recursos que se bloquean, las búsquedas DNS y las colas. Recuerda: el número de peticiones a menudo cuenta más que el tamaño puro del archivo; lo explico exactamente en el artículo sobre la Centrarse en las consultas. La supervisión continua mantiene las optimizaciones estables y mensurables.

Avanzado: HTTP/2/3, CSS no utilizado y mantenimiento de la base de datos

Con HTTP/2/3 me beneficio de la multiplexación, la priorización y una mayor rapidez. Apretones de manos, lo que significa tiempos de espera para cargas paralelas Archivos acortado. Elimino el CSS que no se utiliza para hacer las hojas de estilo más pequeñas y reducir las peticiones. Para las maquetaciones recurrentes, vale el CSS crítico por plantilla, no por página. En la base de datos, elimino revisiones, transitorios caducados y cadáveres de cron para que el backend y las funciones dinámicas sigan siendo rápidos. Estos pasos aceleran notablemente el proceso, sobre todo en proyectos grandes con muchos plugins.

Higiene de plugins y temas

Compruebo regularmente qué plugins duplican funciones o se utilizan poco. convertirse en, y sustituir los paquetes pesados por otros más ligeros Alternativas. Los temas lean, como Astra o GeneratePress, generan muy pocas peticiones y pueden optimizarse limpiamente. Dentro del tema, desactivo los módulos que no necesito, como las colecciones de iconos o los sliders. También configuro los creadores de páginas de forma minimalista para que sólo carguen los widgets que se utilizan. Las banderas de características y las colas modulares ayudan a evitar el desperdicio de archivos.

Uso selectivo de los recursos y establecimiento de prioridades

Además del almacenamiento en caché y la agrupación Consejos sobre recursos los toques finales decisivos. Sólo uso Preload para los recursos realmente críticos: la imagen LCP, el CSS principal (si no está en línea como CSS crítico) y el primario. Webfont-archivo. Demasiadas precargas bloquean la priorización y pueden tener el efecto contrario. Para las fuentes establezco fuente-display (swap/opcional) para evitar el FOIT, y crear una precarga con la correcta como-para que el navegador no cargue el archivo dos veces.

Prelectura de DNS y Preconectar Lo utilizo con moderación para proveedores externos obligatorios (por ejemplo, proveedores de pago en la caja). Preconnect me ahorra el apretón de manos TLS, Sin embargo, esto sólo tiene sentido si el recurso es definitivamente necesario. Prelectura Lo utilizo para recursos que probablemente se necesitarán en el siguiente paso (por ejemplo, la siguiente página de paginación). En relación con Primeras pistas el servidor puede señalar las precargas antes de tiempo - esto reduce el tiempo hasta el primer byte mientras se establece la conexión.

• Precarga: Sólo para imagen LCP, CSS principal, archivo de fuente crítico.
• Preconnect: Para dominios seguros e inevitables de terceros.
• Prefetch: Para recursos/páginas que potencialmente se necesitarán pronto.
• DNS prefetch: Para un trabajo preparatorio bajo pero favorable con hosts externos.

En la medida de lo posible, también utilizo Consejos prioritarios (fetchpriority=“high“ para la imagen LCP) para que el navegador entienda qué es lo que realmente debe ir primero. Esto reduce el tiempo de carga y Secuencia de solicitud control más preciso.

Activos de WordPress: carga sólo lo que necesites

Muchas páginas cargan estilos y scripts de forma global, aunque sólo sean necesarios en algunas plantillas. Identifico tales candidatos y los cargo condicional - Por ejemplo, scripts de formularios sólo en páginas de contacto, CSS de sliders sólo donde existan sliders, y activos de WooCommerce sólo en páginas de tienda, producto y pago.

Un trabajo de limpieza especialmente gratificante:

• Emoji-Desactivar scripts y estilos en el frontend, ya que los sistemas modernos tienen emojis nativos.
• oEmbedfunciona si no hay contenidos de terceros incrustados.
• Dashicons en el frontend si el tema no los requiere.
• Migración jQuery si no hay scripts antiguos colgados.
• Gutenberg bloque-biblioteca Sólo carga CSS si los estilos de bloque se utilizan realmente en el frontend.

Para una gestión precisa de los recursos, recurro a colas modulares (por plantilla/bloque) o utilizo un plugin de optimización que puede desactivar recursos por página. Así se reduce el Lista de solicitudes rápidamente de innumerables archivos a un puñado de activos realmente necesarios.

WooCommerce, formularios y otras áreas dinámicas

Las tiendas tienen sus propios casos especiales: La conocida fragmentos de carros-script puede causar muchas peticiones repetidas a través de admin-ajax.php. Sólo cargo esta función en áreas donde tiene sentido (producto, cesta de la compra, páginas de pago) y la desactivo en blogs o páginas de aterrizaje. Almaceno en caché las minicestas siempre que es posible y sólo las actualizo cuando hay una interacción real. Para las imágenes de producto, utilizo sistemáticamente srcset y preload la primera imagen visible.

Para las formas reduzco Sondeo-intervalos, envío validaciones en paquetes y uso debouncing para que la entrada no se transmita con cada pulsación de tecla. En la medida de lo posible, realizo búsquedas y filtros a través de puntos finales en caché (por ejemplo, REST) para que las peticiones idénticas repetidas se sirvan desde la caché. Esto reduce la carga del servidor, el número de Solicitudes HTTP y mejora la velocidad percibida.

Perfeccionar imágenes, iframes y medios de comunicación

Para la imagen LCP utilizo fetchpriority="alta" y establezco una precarga precisa. Al mismo tiempo, presto atención a anchura/altura o un CSSrelación de aspecto, para que no haya desplazamiento de la disposición. Proporciono imágenes con decodificación="async", para evitar que se bloquee el renderizado, y establece perezoso sólo donde tiene sentido: El primero La imagen no debe ser perezosa, todos los demás deben serlo.

Sustituyo los iframes externos (YouTube, Maps, Social) por avances ligeros. En lugar de cargar todo el widget inmediatamente, muestro una imagen estática de previsualización y sólo cargo la incrustación real después de hacer clic. De este modo, elimino numerosas peticiones iniciales innecesarias para la primera interacción. Para mis propios vídeos, utilizo imágenes de póster, códecs modernos y streaming adaptativo para que ningún archivo de gran tamaño bloquee la sincronización.

Limpieza de cabeceras de caché y eliminación de caché

Muchas peticiones surgen porque las cachés de los navegadores o CDN no funcionan de forma óptima. Defino para activos estáticos (CSS, JS, fuentes, imágenes) TTL largos con Control de la caché y activar la bandera inmutable. Para desplegar actualizaciones de forma segura, utilizo Versionado en los nombres de archivo o WordPressver-parámetros. Importante: La CDN debe almacenar en caché las cadenas de consulta correctamente, de lo contrario perderá ?ver=-los parámetros pierden su efecto y se recarga innecesariamente.

ETag y Última modificación para que las revalidaciones se ejecuten rápidamente y if-none-match/if-modified-since-responses ayudan a ahorrar volumen de datos. Con stale-while-revalidate el sitio sigue respondiendo mientras las actualizaciones se realizan en segundo plano. El resultado es un menor número de idas y vueltas y unas actualizaciones programadas sin caos de caché.

Evite errores: Cuando bundling y minify son demasiado de algo bueno

En HTTP/2/3 No tengo que meter todo en un solo archivo. Los paquetes demasiado grandes Accesos a la caché, porque cada cambio invalida todo el bloque. Yo encuentro un camino intermedio: unos pocos paquetes separados lógicamente que mantienen la ruta crítica pequeña y permiten la reutilización (por ejemplo, un paquete de núcleo global, un paquete de plantilla, un paquete de proveedor que rara vez se cambia).

La minificación también puede causar problemas: Uglify/Minify puede dañar funciones en algunos plugins. Por lo tanto, pruebo paso a paso y excluyo los scripts críticos de Minify/Combine si es necesario (por ejemplo, JSON en línea, scripts de pago, Captcha). El objetivo es más estable, ruta crítica corta, ningún paquete de riesgo que se rompe con cada actualización.

Metodología de medición: pruebas fiables en lugar de conjeturas

Mido con perfiles reproducibles: Escritorio y móvil por separado, con anchos de banda y estrangulamiento de CPU realistas. En las DevTools utilizo Coberturacon el fin de CSS/JS no utilizados y el diagrama de cascada para ver qué peticiones están en espera, apiladas o ralentizadas por prioridades. Comparo Primera vista y Vista repetida, para comprobar si las cabeceras de caché funcionan realmente y si el número de peticiones se reduce realmente a la mitad o más cuando se vuelve a visitar.

También establecí barandillas: número máximo Solicitudes por tipo de página, objetivo LCP, presupuesto para proveedores externos. Las nuevas funciones sólo se activan si se ajustan a los presupuestos. De este modo, el sitio se mantiene rápido a largo plazo, no sólo después de una ronda de optimización.

Sutilezas del lado del servidor: TTFB y TLS

Además del número de peticiones, también cuenta el tiempo de respuesta del servidor. Mantengo OPcache activo, ajustar PHP-FPM, garantizar plug-ins reducidos y minimizar la base de datos.Viajes de ida y vuelta. Con TLS, aseguro una cadena de certificados corta, TLS 1.3 actual y activado Grapado OCSP. Junto con HTTP/3, esto reduce los tiempos de negociación y acelera considerablemente las solicitudes iniciales, especialmente para los usuarios móviles.

Brevemente resumido

Reduzco el número de peticiones activando la caché, agrupando CSS/JS, modernizando las imágenes y retrasando los scripts externos. carga. Alojo las fuentes localmente y precargo los recursos críticos de forma limpia y objetivo. Una CDN con HTTP/2/3 y un alojamiento rápido reducen la latencia y el TTFB. Utilizo mediciones en PageSpeed, Lighthouse y GTmetrix para comprobar si LCP, TBT y CLS se cuelan en el corredor objetivo. En pocas horas, este proceso suele hacer que se pase de las lentas solicitudes de más de 70 a páginas rápidas que están muy por debajo de 50.