Optimización de rendimiento en Drupal: caché, BigPipe y Varnish

Drupal es una de las plataformas más potentes para construir sitios corporativos, portales complejos y aplicaciones web a medida, pero arrastra una fama injusta: la de ser «pesado». La realidad es que un Drupal mal configurado puede ir lento y uno bien optimizado puede volar. La diferencia casi nunca está en el núcleo de Drupal, sino en cómo se aprovecha su sistema de caché y en las decisiones de arquitectura que se toman durante el desarrollo.

En esta guía repasamos, de forma práctica y ordenada, cómo optimizar el rendimiento de Drupal: desde las distintas capas de caché (cache tags, cache contexts, Dynamic Page Cache y BigPipe) hasta Varnish, los backends Redis o Memcache, la optimización del frontend para los Core Web Vitals y el ajuste de PHP, la base de datos y el servidor. El objetivo es que tu sitio responda en milisegundos incluso bajo picos de tráfico.

Si gestionas un proyecto Drupal exigente y quieres que el rendimiento deje de ser un problema recurrente, en Keliam abordamos la velocidad como un requisito desde el primer sprint. Puedes ver cómo trabajamos en nuestros servicios de desarrollo y mantenimiento Drupal.

Rendimiento en Drupal: por qué la caché es tu mejor aliada

Drupal tiene fama de ser una plataforma potente pero pesada. La realidad es que un Drupal bien configurado puede servir miles de peticiones por segundo con tiempos de respuesta inferiores a 100 milisegundos. La diferencia entre un Drupal lento y uno rápido no está en la plataforma — está en cómo se configura su sistema de caché y en las decisiones de arquitectura que se toman durante el desarrollo.

En los proyectos de desarrollo Drupal que gestionamos en Keliam, la optimización de rendimiento es un requisito desde el primer sprint, no algo que se aborda al final cuando las cosas van lentas.

Los niveles de caché de Drupal, de menor a mayor

Antes de entrar en detalle conviene entender que Drupal no tiene «una caché», sino varias capas que colaboran. Conocerlas evita el error más común: vaciar toda la caché ante cualquier problema en lugar de actuar sobre la capa adecuada.

La Internal Page Cache sirve páginas completas a usuarios anónimos directamente desde la caché, sin ejecutar apenas lógica de Drupal. Es el mecanismo más rápido y el que más impacto tiene en sitios con mucho tráfico anónimo (blogs, portales, catálogos). La Dynamic Page Cache va un paso más allá: cachea también páginas que contienen elementos dinámicos, sustituyéndolos por placeholders que se rellenan en el momento, de modo que usuarios autenticados también se benefician de la caché. Por debajo, la Render Cache almacena fragmentos individuales (bloques, vistas, campos) a partir de los render arrays, para que cada componente se reconstruya solo cuando realmente cambia.

La clave está en que estas capas se apoyan en un sistema de metadatos de caché —tags, contexts y max-age— que Drupal propaga automáticamente. Entenderlo es lo que separa una caché que «a veces muestra contenido viejo» de una caché fiable y granular.

Cache tags y cache contexts: la invalidación inteligente

El sistema de caché de Drupal es uno de los más sofisticados entre los CMS. Los cache tags permiten invalidar selectivamente fragmentos de caché cuando cambia un contenido específico, sin tener que vaciar toda la caché. Los cache contexts permiten servir versiones diferentes de una página según el idioma, el rol del usuario, la URL o cualquier otra variable, manteniendo cada variante en caché de forma independiente.

Y los cache max-age definen el tiempo de vida de cada fragmento. La combinación de estos tres mecanismos permite una estrategia de caché extremadamente granular: puedes cachear una página entera durante horas pero invalidar solo el bloque de últimas noticias cuando se publica un artículo nuevo. Un error frecuente al desarrollar módulos o bloques personalizados es olvidar declarar los cache tags correctos: el resultado es contenido que no se actualiza o, al revés, una caché que nunca acierta.

BigPipe y Lazy Builder: personalización sin sacrificar caché

Uno de los retos clásicos del rendimiento web es servir páginas cacheadas cuando hay elementos personalizados (nombre del usuario, carrito de compra, contenido geolocalizado). Drupal resuelve esto con BigPipe, que envía la página cacheada inmediatamente y rellena los bloques personalizados de forma asíncrona, y con Lazy Builders, que difieren la renderización de componentes costosos.

Con BigPipe activado, el usuario percibe una carga casi instantánea porque el HTML estático llega inmediatamente, mientras los componentes dinámicos se renderizan en paralelo. Es una solución elegante que evita tener que elegir entre personalización y velocidad. Si tu proyecto separa por completo el frontend del backend, muchas de estas piezas cambian de sitio: lo explicamos en nuestra guía sobre Drupal headless y cuándo desacoplar el frontend.

Varnish como capa de caché HTTP

Para sitios con tráfico significativo, Varnish delante de Drupal es prácticamente imprescindible. El módulo Purge de Drupal se integra nativamente con Varnish para enviar invalidaciones de caché basadas en los cache tags. Esto significa que Varnish puede servir páginas sin tocar Drupal, pero se invalida automáticamente y de forma selectiva cuando el contenido cambia.

La configuración del VCL (Varnish Configuration Language) requiere atención al detalle: gestionar correctamente las cookies de sesión para no cachear contenido personalizado, diferenciar entre usuarios anónimos y autenticados, y definir las reglas de purga por cache tag. Una alternativa cada vez más habitual es delegar esta capa en un CDN con soporte de invalidación por tags (Fastly, Cloudflare o similares), que aporta además distribución geográfica y protección frente a picos.

Backends de caché: Redis y Memcache

Por defecto, Drupal guarda sus cachés (y a menudo las sesiones y la cola) en la base de datos. Funciona, pero bajo carga la base de datos se convierte en cuello de botella. Mover los bins de caché a Redis o Memcache descarga MySQL/MariaDB y acelera drásticamente las lecturas y escrituras de caché.

Redis es hoy la opción más recomendada porque, además de caché, permite gestionar sesiones y bloqueos, y ofrece persistencia opcional. En sitios medianos y grandes, este cambio por sí solo suele reducir de forma notable el tiempo de respuesta del backend y mejora la estabilidad cuando llegan muchas peticiones simultáneas. La configuración es sencilla con los módulos oficiales, pero conviene definir bien qué bins se externalizan y vigilar el consumo de memoria.

Optimización del frontend: agregación, imágenes y Core Web Vitals

Un backend rápido no sirve de nada si el navegador tarda en pintar la página. Drupal incorpora agregación y minificación de CSS y JavaScript, que reducen el número de peticiones y el peso de los assets; combinarla con compresión Brotli o gzip y con HTTP/2 o HTTP/3 marca una diferencia clara en la carga inicial.

Las imágenes son casi siempre el recurso más pesado. Usar los image styles de Drupal para servir tamaños adecuados, adoptar formatos modernos como WebP o AVIF, aplicar loading="lazy" y reservar espacio para evitar saltos de layout mejora tanto la velocidad como la estabilidad visual. Todo esto impacta directamente en los Core Web Vitals, las métricas de rendimiento que Google usa para el SEO: LCP (mayor elemento visible), CLS (estabilidad) e INP (capacidad de respuesta a la interacción, que sustituyó a FID en 2024). Cuidar la accesibilidad y el cumplimiento legal en paralelo también es parte de una web bien hecha, como vemos en nuestra guía de accesibilidad y RGPD en Drupal.

Base de datos, PHP y servidor

El rendimiento también se juega en la capa de infraestructura. En PHP, tener OPcache activado y bien dimensionado es obligatorio: cachea el bytecode y evita recompilar el código en cada petición. Ajustar el número de procesos de PHP-FPM al tráfico y a la memoria disponible evita tanto los cuellos de botella como el consumo excesivo de RAM.

En la base de datos, revisar índices, consultas lentas y la configuración de MariaDB o MySQL (buffers, tamaño de caché) es clave en sitios con muchos contenidos o integraciones. Precisamente las integraciones de Drupal con APIs, CRMs y sistemas externos pueden penalizar el rendimiento si se ejecutan de forma síncrona en cada carga: conviene cachear sus respuestas o moverlas a procesos en segundo plano mediante la cola de Drupal y cron. Por último, usar una versión moderna de PHP (8.3 o 8.4) aporta mejoras de rendimiento notables frente a versiones antiguas.

Herramientas de diagnóstico y métricas

No puedes optimizar lo que no mides. El módulo WebProfiler (parte de Devel) muestra información detallada de cada petición: queries SQL ejecutadas, tiempo de cada una, cache hits y misses, y hooks invocados. Para producción, herramientas como New Relic o Blackfire.io permiten perfilar el rendimiento a nivel de aplicación y detectar cuellos de botella en código personalizado.

A nivel de infraestructura, monitorizar el hit rate de Varnish, los tiempos de respuesta del backend PHP y el uso de memoria de los procesos PHP-FPM es fundamental para mantener el rendimiento a lo largo del tiempo. Conviene combinar datos de laboratorio (Lighthouse, WebPageTest) con datos de campo reales de usuarios, que son los que Google tiene en cuenta para el SEO. Si tu Drupal va lento o necesitas prepararlo para un pico de tráfico, podemos ayudarte a diagnosticar y resolver los problemas de rendimiento.

Errores comunes de rendimiento en Drupal

Muchos problemas de velocidad no vienen de la plataforma, sino de decisiones evitables. Estos son los que más nos encontramos al auditar proyectos:

• Vaciar toda la caché ante cualquier duda: en vez de corregir los cache tags de un módulo, se recurre a drush cr constantemente, lo que dispara la carga tras cada despliegue.
• Módulos personalizados sin metadatos de caché: bloques o vistas que devuelven contenido sin declarar tags ni max-age, obligando a Drupal a renderizar en cada petición.
• Vistas sin caché o mal filtradas: listados pesados que consultan miles de nodos sin paginación ni caché de vista.
• Demasiados módulos contribuidos: cada módulo añade hooks y consultas; instalar por instalar penaliza el rendimiento.
• Imágenes sin optimizar: subir originales de varios MB y servirlos sin image styles ni formatos modernos.
• Integraciones síncronas: llamar a APIs externas en cada carga en lugar de cachear o encolar las respuestas.

Drupal en 2026: versiones y rendimiento

La rama actual es Drupal 11, con versiones menores frecuentes (11.4.x a mediados de 2026) que van incorporando mejoras de rendimiento y compatibilidad con las últimas versiones de PHP y Symfony. Está previsto que Drupal 12 llegue a finales de 2026, y el proyecto mantiene una política de actualización continua que hace las transiciones mucho menos traumáticas que en el pasado.

La gran novedad de los últimos años es Drupal CMS (la iniciativa antes conocida como Starshot): una distribución lista para usar, pensada para acelerar el arranque de proyectos con funcionalidades preconfiguradas. Si quieres el detalle, lo cubrimos en el artículo sobre las novedades de Drupal 11 y Starshot. Mantener el CMS y PHP actualizados no es solo una cuestión de seguridad: cada salto de versión suele traer mejoras de rendimiento «gratis». En arquitecturas con varios sitios, conviene además planificar bien la estrategia de Drupal multisite para no multiplicar los costes de mantenimiento.

Mantenimiento y mejora continua del rendimiento

El rendimiento no es un hito que se alcanza una vez, sino un objetivo que se mantiene. Cada release, cada módulo nuevo y cada campaña de tráfico pueden alterar el equilibrio. Establecer revisiones periódicas, alertas sobre tiempos de respuesta y una auditoría técnica anual evita que el sitio se degrade sin que nadie lo note. Este enfoque de mejora continua es, además, el mismo que promueven los marcos de gestión de seguridad como la ISO 27001: medir, actuar y revisar de forma cíclica.

Cron, colas y hosting: el rendimiento que no se ve

Buena parte del trabajo de un sitio ocurre fuera de la petición del usuario. El cron de Drupal ejecuta tareas de mantenimiento (indexación de búsqueda, limpieza de caché caducada, envío de correos, actualizaciones). Ejecutarlo mediante el cron real del sistema operativo —en lugar del cron «automático» que se dispara con las visitas— evita que un usuario pague el coste de esas tareas y hace el rendimiento más predecible.

La Queue API permite diferir trabajo pesado (procesar imágenes, sincronizar con un ERP o CRM, generar informes) a procesos en segundo plano, de modo que la respuesta al usuario sea inmediata y el trabajo costoso se reparta en el tiempo. Es una de las herramientas más infrautilizadas y, a la vez, de mayor impacto en sitios con muchas integraciones.

Por último, nada de esto rinde si el hosting no acompaña. Un servidor con discos SSD/NVMe, suficiente RAM para OPcache y Redis, HTTP/2 o HTTP/3 y una versión moderna de PHP es la base sobre la que se construye todo lo demás. Un alojamiento barato y saturado echa por tierra la mejor configuración de caché. Si no estás seguro de si tu infraestructura está a la altura, una auditoría técnica te dará una foto clara del punto de partida.

Preguntas frecuentes sobre el rendimiento en Drupal

¿Drupal es más lento que WordPress? No de forma inherente. Con su caché bien configurada, Drupal maneja muy bien sitios grandes y complejos. Las diferencias reales dependen de la calidad del desarrollo, el hosting y la estrategia de caché, no del CMS en abstracto.

¿Necesito Varnish sí o sí? No para todos los proyectos. Un sitio pequeño con tráfico moderado puede ir sobrado con la Internal Page Cache y un buen hosting. Varnish (o un CDN equivalente) aporta valor cuando hay tráfico alto o picos frecuentes.

¿Qué mejora el rendimiento más rápido? Normalmente, activar y configurar bien la caché de páginas, mover la caché a Redis y optimizar las imágenes. Son cambios de alto impacto y bajo riesgo.

¿Con qué frecuencia debo revisar el rendimiento? Como mínimo tras cada despliegue importante y en una revisión trimestral, además de monitorizar de forma continua los tiempos de respuesta y los Core Web Vitals.

Conclusión

Optimizar Drupal no consiste en un truco mágico, sino en aprovechar bien un sistema de caché que es, probablemente, el más avanzado entre los CMS. Entender sus capas, declarar correctamente los metadatos de caché, apoyarse en Varnish o un CDN, externalizar la caché a Redis, cuidar el frontend para los Core Web Vitals y ajustar PHP, la base de datos y el servidor es lo que convierte un Drupal lento en uno capaz de servir miles de peticiones por segundo con tiempos por debajo de 100 milisegundos.

Y como el rendimiento se degrada con el tiempo si no se vigila, la clave está en tratarlo como parte del mantenimiento continuo del proyecto, no como una tarea aislada.