Cómo Optimizar el Rendimiento y Velocidad de una Web Drupal

La velocidad importa. Desde 2018 Google la trata como factor de posicionamiento confirmado, y desde 2021 con Core Web Vitals es aún más determinante. Una web Drupal bien construida puede ir muy rápida, pero sin la configuración adecuada va a ir bastante más lenta de lo que debería.

En este artículo te cuento, con la perspectiva de haberme pegado con bastantes proyectos, cómo optimizar el rendimiento y velocidad de una web Drupal sin reescribir medio sitio. De la configuración básica a las optimizaciones de servidor y frontend.

Por Qué el Rendimiento Importa en Drupal

Drupal es un CMS potente, pero con bastante más complejidad que WordPress o Webflow. Esa arquitectura modular que tanto te da en flexibilidad también es la que te penaliza: si acumulas módulos sin control o la caché está mal configurada, el rendimiento se degrada antes de lo que esperas.

Los sitios Drupal sin optimizar suelen mostrar un patrón reconocible:

• TTFB (Time to First Byte) superiores a 500ms
• Puntuaciones PageSpeed inferiores a 60 en móvil
• Tiempos de carga totales de 5 a 8 segundos en páginas complejas

Llegar a TTFB por debajo de 200ms y PageSpeed superior a 85 es perfectamente realizable. La clave está en entender las capas del sistema y actuar sobre cada una de forma ordenada, no a martillazos.

1. Configuración de Caché en Drupal

La caché es la palanca con más impacto, sin discusión. Drupal tiene un sistema multicapa que, bien configurado, reduce drásticamente la carga del servidor. Por aquí empiezas siempre.

Caché de Páginas (Internal Page Cache)

En /admin/config/development/performance, activa la caché de páginas para usuarios anónimos. Internal Page Cache almacena la respuesta HTML completa. Para contenido que no cambia varias veces al día, 3.600 segundos (una hora) es un punto de partida razonable. Solo con esto el rendimiento para visitantes anónimos pega un salto enorme.

Caché de Renderizado (Render Cache)

Drupal cachea bloques, vistas y entidades por separado usando cache tags y cache contexts, así que solo se invalida lo que cambia sin reconstruir toda la página. Un problema que veo recurrente: módulos o temas custom que ponen max-age = 0 en elementos que perfectamente podrían cachearse, desactivando la caché de renderizado sin querer.

BigPipe

El módulo BigPipe (incluido en Drupal core desde 8.x) envía el contenido estático de la página inmediatamente y deja que los bloques dinámicos se carguen de forma asíncrona. Actívalo: la mejora en rendimiento percibido es notable y no te obliga a sacrificar personalización.

Varnish Cache

Para sitios con tráfico significativo, Varnish actúa como proxy inverso delante de Drupal y sirve páginas cacheadas directamente desde memoria, sin tocar PHP. Impacto drástico: TTFBs por debajo de 50ms para páginas cacheadas frente a 200-500ms sin Varnish.

Necesitas el módulo Purge junto con Varnish Purger para invalidar páginas cuando el contenido cambia. La VCL específica para Drupal la tienes documentada en el módulo oficial.

Redis o Memcached para Caché de Backend

Por defecto Drupal guarda la caché en la base de datos, y con tráfico alto te penaliza. Mover esa caché a un almacén en memoria como Redis o Memcache reduce la carga del MySQL y acelera la lectura. Yo veo Redis como la opción más extendida en 2026 por su versatilidad y por el soporte nativo en la mayoría de hostings Drupal.

2. Optimización de Assets (CSS y JavaScript)

Agregación y Minificación

En /admin/config/development/performance, activa “Aggregate CSS files” y “Aggregate JavaScript files”. Reduces peticiones HTTP y peso total sin tocar una línea de código. La victoria más barata de toda la lista.

Módulo AdvAgg

Advanced CSS/JS Aggregation (AdvAgg) va más allá: minificación más agresiva, compresión Brotli y control granular sobre qué assets se agregan. Si el agregado nativo se queda corto, este es el siguiente paso.

Critical CSS

Identifica e inserta en línea el CSS necesario para renderizar la parte visible (above the fold) y deja que el resto se cargue diferido. Herramientas como Critical o Penthouse generan ese CSS crítico automáticamente. La mejora en LCP (Largest Contentful Paint) se nota en métricas y en uso real.

3. Optimización de Imágenes

Las imágenes son, casi siempre, el mayor contribuyente al peso de la página. Una optimización seria de imágenes puede reducir el peso total entre un 40% y un 70%. Aquí se ganan kilobytes rápido.

Image Styles de Drupal

Configura estilos de imagen para generar versiones optimizadas según el contexto: miniaturas para listados, medianas para contenido, grandes para hero images. Nunca sirvas una imagen más grande de lo necesario; el navegador la escalará y habrás pagado el peso para nada.

Módulo ImageAPI Optimize

ImageAPI Optimize integra con jpegoptim, pngquant o APIs externas (TinyPNG) para reducir el peso sin pérdida visual apreciable. Reducción típica del 30% al 60%. Lo configuras una vez y trabaja por ti en cada subida.

WebP y AVIF

Drupal 10 soporta WebP nativamente, que pesa un 25-35% menos que JPEG para calidad equivalente. AVIF comprime aún más, pero el soporte de navegadores todavía no está al mismo nivel. Si tu versión lo permite, WebP es ganancia gratis.

Lazy Loading

Drupal 10 trae lazy loading nativo. Las imágenes fuera del viewport inicial no se cargan hasta que el usuario hace scroll, reduciendo el tiempo percibido y el ancho de banda. Compruébalo tras cada actualización: a veces un tema custom pisa el atributo y se queda sin efecto.

4. Optimización de Base de Datos

Índices y Consultas Lentas

En sitios con contenido complejo o muchos módulos las consultas lentas aparecen pronto. Usa EXPLAIN en MySQL o MariaDB para detectar consultas sin índices adecuados. Las Views de Drupal generan consultas que se benefician mucho de índices compuestos. En producción, el slow query log es tu mejor amigo: actívalo, déjalo correr unos días y mira qué aparece.

Consultas N+1

El clásico: una vista de 50 nodos ejecuta una consulta por nodo para cargar referencias, en vez de una sola con JOIN. Views tiene opciones de agregación y la carga de entidades la optimizas con loadMultiple. Lo primero que reviso cuando un listado va lento es esto.

Limpieza y Mantenimiento

Las tablas de caché y de sesiones crecen sin control si no se vigilan. Ejecuta drush cr con regularidad y configura la limpieza automática de sesiones expiradas. El módulo DB Maintenance, o los comandos Drush equivalentes, optimizan las tablas sin meterte a mano en SQL.

Eliminar Módulos No Usados

Cada módulo activo añade hooks que se ejecutan en cada petición, los uses o no. Desactiva y desinstala todo lo que no estés usando. Un Drupal típico arrastra entre 10 y 20 módulos activados “por si acaso” hace años que solo suman overhead.

Configuración de MySQL/MariaDB

Dos parámetros que merece la pena revisar en cualquier servidor dedicado:

• innodb_buffer_pool_size: entre el 60% y el 80% de la RAM disponible.
• max_connections: ajustado al número de procesos PHP concurrentes, no más, no menos.

5. Servidor y PHP

PHP OPcache

OPcache compila el código PHP y lo guarda en memoria compartida. Imprescindible, no opcional. Configuración recomendada: opcache.memory_consumption = 256, opcache.max_accelerated_files = 20000, opcache.validate_timestamps = 0 en producción. Es lo primero que reviso cuando alguien me dice que su Drupal va lento y “no entiende por qué”.

Versión de PHP

Usa la última versión estable compatible con tu Drupal. PHP 8.3 es un 10-20% más rápido que PHP 8.1 en cargas típicas de Drupal. Cada versión mayor trae mejoras que recoges sin tocar nada de tu código.

PHP-FPM

PHP-FPM gestiona los procesos PHP. Cada worker consume 30-80 MB de RAM. Fórmula orientativa: max_children = RAM disponible para PHP / consumo medio por worker. Modo dynamic para tráfico variable, static para tráfico constante y alto. Mide concurrencia real antes de tocar los números.

Nginx vs. Apache

Nginx consume menos memoria bajo carga y maneja las conexiones concurrentes mejor que Apache. Para Drupal con tráfico alto, ponerlo como servidor web o como proxy inverso es lo que recomiendo casi sin excepción.

CDN para Assets Estáticos

Una CDN (Cloudflare, Fastly, AWS CloudFront) distribuye CSS, JavaScript e imágenes en servidores cercanos al usuario. La integración en Drupal es sencilla: defines el dominio del CDN como base URL para estáticos en settings.php o usas el módulo CDN. Para audiencia internacional no es opcional.

Cron de Drupal

Configura el cron de Drupal externamente, con un cron del sistema operativo que llame a drush cron, en vez de dispararse con cada petición web. Ejecutarlo en cada petición añade latencia innecesaria al usuario, y es uno de esos detalles que solo salen cuando alguien lo busca.

6. Herramientas de Medición

Antes y después de cada optimización, mide. Sin números no estás optimizando, estás adivinando. Mis referencias:

• Google PageSpeed Insights: métricas Core Web Vitals reales y de laboratorio.
• GTmetrix: waterfall de carga, útil para ver qué recurso bloquea a qué.
• WebPageTest: múltiples ubicaciones y conexiones para una foto realista.
• Drush: drush cache-rebuild y drush core-requirements para diagnóstico de la instalación.
• New Relic o Blackfire: profiling avanzado en producción cuando los problemas no son evidentes desde fuera; identifican funciones y consultas lentas.
• Devel + Webprofiler: en desarrollo, muestran consultas SQL, tiempos de renderizado y uso de caché por petición.

Orden Recomendado de Optimización

El orden que mejor me funciona en proyectos reales, respetando cómo cada capa se apoya en la anterior:

1. Caché primero (Internal Page Cache, render cache, Varnish).
2. Assets (agregación CSS/JS, Critical CSS).
3. Imágenes (estilos, compresión, WebP, lazy loading).
4. Base de datos (índices, consultas lentas, limpieza).
5. Servidor (PHP, OPcache, Redis, CDN).
6. Módulos (desactivar lo innecesario).

Cuando aplicas las medidas en este orden, cada una aprovecha el terreno que dejó la anterior. Saber cómo optimizar el rendimiento y velocidad de una web Drupal es, sobre todo, un proceso iterativo: cada sitio tiene cuellos de botella distintos.

Si tu web Drupal va lenta o quieres que revisemos el rendimiento antes de un relanzamiento, hablamos y lo evaluamos juntos.