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-rebuildydrush core-requirementspara 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:
- Caché primero (Internal Page Cache, render cache, Varnish).
- Assets (agregación CSS/JS, Critical CSS).
- Imágenes (estilos, compresión, WebP, lazy loading).
- Base de datos (índices, consultas lentas, limpieza).
- Servidor (PHP, OPcache, Redis, CDN).
- 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.
Artículos relacionados
Preguntas frecuentes
Las dudas más comunes. Si la tuya no está, pregúntanos
En Tangram no queremos que la información pase por una cadena interminable de intermediarios donde se pierden los detalles importantes.
Contarás con un interlocutor que coordinará la comunicación y trasladará las decisiones al equipo responsable de tu proyecto.
Cuando sea necesario profundizar en cuestiones de estrategia, diseño o tecnología, podremos involucrar a los especialistas correspondientes.
Así tendrás una comunicación organizada, sin necesidad de gestionar personalmente a todos los profesionales que intervienen.
Queremos que tengas acceso al conocimiento de un equipo especializado, sin sufrir la complejidad de coordinarlo.
No tendrás que averiguar a quién escribir cada vez que tengas una duda.
En Tangram contemplamos la figura del Account Manager como interlocutor principal, encargado de acompañarte durante el proyecto, coordinar la comunicación y facilitar el seguimiento de las decisiones.
Nuestra metodología incluye reuniones de revisión, canales de comunicación y herramientas para que puedas participar en el trabajo.
La organización concreta, la frecuencia de las reuniones y los canales disponibles se establecerán según el proyecto contratado.
Lo importante es que sepas con quién hablar, en qué punto está tu proyecto y qué decisiones necesitan tu participación.
Sí, podemos valorar una colaboración con los profesionales que ya trabajan en tu empresa.
No siempre tiene sentido sustituir un equipo que conoce bien tu negocio. En muchas situaciones, lo más útil es complementar sus conocimientos con especialistas en determinadas áreas.
Podemos estudiar qué responsabilidades asumiría Tangram, cuáles mantendría tu equipo y cómo coordinar las decisiones para evitar duplicidades.
La forma concreta de colaboración dependerá de la organización, las herramientas y las necesidades del proyecto.
No se trata de reemplazar lo que ya funciona, sino de aportar el conocimiento que necesitas para llegar más lejos.
No tienes por qué cambiar de proveedor para explorar una colaboración con Tangram.
Durante nuestra trayectoria hemos trabajado con agencias y consultoras, participando en proyectos en los que cada empresa asumía una parte diferente del trabajo.
Esa experiencia nos permite comprender la importancia de definir responsabilidades y coordinar a los profesionales implicados.
Podemos valorar una colaboración para cubrir necesidades concretas que tu proveedor actual no ofrece o para reforzar determinadas áreas.
Si tienes una relación profesional que funciona, no queremos que la rompas sin motivo. Queremos encontrar dónde podemos aportar valor.
La confidencialidad es especialmente importante cuando hablamos de nuevas ideas de negocio, información económica, estrategias comerciales o desarrollos tecnológicos.
En Tangram tenemos experiencia trabajando en proyectos sujetos a acuerdos de confidencialidad, motivo por el que no podemos mostrar públicamente muchos de los trabajos en los que hemos participado.
Si tu proyecto requiere un acuerdo de confidencialidad (NDA) antes de compartir información sensible, podemos revisar sus condiciones y acordar cómo proteger esa información antes de entrar en los detalles.
Entendemos que la confianza empieza por respetar lo que todavía no quieres hacer público.