Los sitios web universitarios funcionan con holgura durante la mayor parte del año y tienen dificultades en unos pocos días de mucha actividad. La causa rara vez es un servidor insuficiente. Lo que ocurre es que, en esos días, la mayoría de las páginas ya no pueden servirse desde una copia almacenada. Este artículo explica, en términos sencillos, cómo almacena Drupal las páginas, qué acelera una CDN y qué no, y por dónde empezar si quiere que el sitio resista.
Una página carga en medio segundo en marzo y tarda diez segundos la primera mañana del periodo de matrícula. El mismo sitio, el mismo código. Lo único que cambió es cuántas páginas tuvo que construir el servidor desde cero ese día. Acelerar un sitio en Drupal consiste, sobre todo, en reducir esa cifra.
¿Cuándo se ralentiza realmente un sitio web universitario?
Durante la mayor parte del año, la mayoría de los visitantes no ha iniciado sesión. Los futuros estudiantes consultan los programas, los padres abren la página de contacto y los buscadores rastrean la sección de noticias. Todas esas visitas pueden atenderse desde una copia almacenada, y el servidor apenas trabaja.
En los días de mucha actividad, esa proporción cambia. Una gran parte de los visitantes son ahora estudiantes con sesión iniciada. En cuanto alguien inicia sesión, la página pasa a ser personal y una copia almacenada para todos ya no sirve. El servidor empieza a construir miles de páginas desde cero al mismo tiempo.
A eso se suman otros dos factores. Las plazas disponibles y los horarios se leen de otro sistema y no pueden conservarse mucho tiempo, porque no deben quedar desactualizados. Y cuando cambia el calendario académico o un aviso dirigido a toda la universidad, hay que reconstruir todas las páginas que muestran esa información.
Cuando los tres factores coinciden en la misma semana, el sitio se ralentiza. El objetivo no es arañar milisegundos en un día normal. Es superar esos días sin una caída del servicio.
Cómo almacena Drupal las páginas
Después de construir una página, Drupal guarda una copia. La siguiente persona que solicita esa misma página recibe la copia almacenada en lugar de esperar a que se construya de nuevo. Esta es la principal razón por la que un sitio en Drupal resulta rápido, y funciona sin configuración adicional.
Para visitantes que no han iniciado sesión
Este es el caso fácil. Todos ven la misma página, así que una sola copia almacenada sirve para todos. Las páginas de programas, las noticias y los datos de contacto llegan a miles de personas desde la misma copia, y el servidor casi no hace nada.
Para usuarios con sesión iniciada
En el momento en que alguien inicia sesión, una parte de la página pasa a ser solo suya: su nombre, sus notificaciones, sus asignaturas. Ya no se puede utilizar una única copia almacenada para todos.
Drupal lo resuelve dividiendo la página en dos. Sigue almacenando las partes que son iguales para todos y reconstruye en cada visita solo las partes personales. Así, se reconstruye una fracción de la página en lugar de la página entera.
Si esas partes personales siguen siendo lentas, entra en juego BigPipe. Este enfoque se desarrolló originalmente en Facebook, y Drupal lo incorporó a su núcleo. Su funcionamiento es sencillo: las partes compartidas de la página se envían de inmediato y las partes personales llegan en cuanto están listas, de modo que el visitante ve cómo se completa la página en lugar de quedarse mirando una pantalla en blanco. Según la documentación de Drupal, BigPipe está activado por defecto en la instalación estándar desde la versión 8.5, lo que significa que ya funciona en la mayoría de los sitios.
| Visitantes sin sesión iniciada | Usuarios con sesión iniciada | |
|---|---|---|
| Cómo llega la página | Desde una copia almacenada | Partes compartidas almacenadas, partes personales reconstruidas |
| Coste para el servidor | Casi ninguno | Algo de trabajo en cada visita |
| Riesgo en un día de mucha actividad | Bajo | Aquí se concentra la carga |
Qué ocurre cuando cambia el contenido
Lo difícil de almacenar páginas no es llenar el almacén, sino actualizar las páginas correctas en el momento adecuado. En un sitio web universitario, la misma información aparece en decenas de lugares. El nombre de un profesor figura a la vez en el listado de un departamento, en la página de una asignatura y en una noticia.
Drupal registra de qué contenido depende cada página almacenada. Cuando ese contenido cambia, actualiza solo las páginas que dependen de él y deja el resto intacto. Un cambio de nombre no se propaga por todo el sitio.
El verdadero error aquí es la costumbre de vaciarlo todo después de cada edición. Eso obliga a reconstruir el sitio entero, y suele hacerse en el peor momento posible. La solución es dejar de tratar ese botón como parte de la rutina diaria.
Qué acelera una CDN y qué no
Una CDN sirve los archivos de un sitio desde servidores repartidos por todo el mundo, de modo que las imágenes, los vídeos y las fuentes llegan desde un lugar cercano al visitante. En los sitios universitarios, esos archivos representan la mayor parte del peso de la página, así que la mejora es real.
En el lado de Drupal, de esto se encarga el módulo CDN. Hay un detalle que afecta a la planificación: la versión estable funciona con Drupal 9 y 10, mientras que la compatibilidad con Drupal 11 aún está en pruebas. Una institución que ya utiliza Drupal 11 debería saberlo de antemano.
Tras la instalación suele llegar un error habitual: una vez que la CDN está en marcha, se da por resuelto el problema de rendimiento. Pero una CDN distribuye archivos ya terminados; no construye páginas. La página personal que ve un estudiante con sesión iniciada se construye cada vez en el propio servidor de la institución, y ahí es donde se concentra la carga en un día de mucha actividad.
Las páginas de los servicios informáticos universitarios lo dicen con claridad. Las directrices sobre Drupal de una gran universidad pública advierten a los responsables de sitios que su CDN solo se aplica a los visitantes sin sesión iniciada, y que los usuarios con sesión iniciada la omiten por completo. Stanford lleva esta distinción un paso más allá. Sus servicios informáticos describen una plataforma Drupal gestionada de forma centralizada para los sitios de departamentos y unidades, con una opción de alojamiento independiente para los sitios con mucho tráfico. No todos los sitios reciben el mismo tratamiento.
Páginas que muestran datos en tiempo real
Las plazas disponibles, los horarios y las calificaciones proceden de otro sistema y no pueden quedar desactualizados. Como no se pueden almacenar, son las páginas más costosas del sitio.
Tres medidas sencillas ayudan. Primero, separe el elemento en tiempo real del resto de la página, de modo que solo esa pequeña parte se reconstruya cada vez y todo lo que la rodea siga almacenado. Segundo, asígnele una vida útil corta en lugar de ninguna. Un número de plazas con hasta un minuto de antigüedad es aceptable en la mayoría de las situaciones, y ese minuto le ahorra al otro sistema miles de consultas. Tercero, decida qué muestra la página cuando el otro sistema no responde. Mostrar la última cifra conocida con su marca de tiempo es mejor que no mostrar nada.
Tratamos la parte de datos de estas páginas en el artículo Integración de Drupal con el sistema de información estudiantil.
Gestionar muchos sitios desde una sola plataforma
Muchas universidades gestionan decenas de sitios de facultades y unidades desde una única instalación. De ahí surge una suposición frecuente: como los sitios comparten plataforma, las copias almacenadas también deben compartirse. No es así. Cada sitio conserva las suyas.
Esto tiene dos consecuencias. Una mejora realizada en un sitio no se traslada por sí sola a los demás. Y como los sitios que comparten un servidor también comparten sus recursos, una semana intensa para un departamento puede ralentizar las páginas de otro.
Las ventajas e inconvenientes más amplios de esta configuración se tratan en el artículo Gestión de sitios web universitarios con Drupal multisitio. En cuanto al rendimiento, la conclusión práctica es identificar qué sitios tienen picos de tráfico y planificar para ellos por separado.
Qué medir
Las herramientas de medición tienen un punto ciego que conviene conocer. La mayoría prueba el sitio sin iniciar sesión, por lo que nunca ven las páginas que fallan en un día de mucha actividad. Una página de inicio puede obtener una puntuación perfecta mientras la pantalla de selección de asignaturas se cae.
Por eso se necesitan dos perspectivas. La primera abarca las páginas que los visitantes ven sin iniciar sesión. Las métricas de velocidad de Google evalúan esa parte e influyen en el posicionamiento en buscadores; las tratamos en el artículo SEO en Drupal. La segunda abarca las páginas que ven los usuarios con sesión iniciada, medidas en el servidor y no en el navegador, y ahí suele estar el verdadero problema.
La medición más útil ya está a su alcance. Los registros del servidor de su semana de mayor actividad del año pasado le dirán más que cualquier herramienta de pruebas. En ellos consta qué páginas se solicitaron a qué hora y qué solicitudes nunca llegaron a completarse.
Por dónde empezar
Da buen resultado empezar al menos un mes antes del pico y seguir este orden.
Comience por comprobar que la configuración de caché está activada. Es una comprobación de media hora, pero en los sitios donde algo estaba desactivado es lo que más diferencia marca de toda la lista.
A continuación, revise las páginas que ven los usuarios con sesión iniciada y determine qué partes son realmente personales. En la mayoría de los sitios son menos de lo esperado, y todo lo demás puede hacerse almacenable.
Después, separe los elementos que muestran datos en tiempo real, asigne a cada uno una vida útil razonable y decida qué muestra cada uno cuando el otro sistema no está disponible.
Por último, realice una prueba basada en la hora de mayor actividad del año pasado. Esa prueba debe ejecutarse como usuario con sesión iniciada; de lo contrario, nunca se ponen a prueba las páginas que causan el problema.
Conviene ajustar las expectativas al mismo tiempo que se trabaja. Drupal ofrece herramientas potentes en este terreno, pero no llegan ajustadas a su institución. Decidir cuánto puede desactualizarse cada dato es una decisión institucional, no técnica, y se toma con la secretaría académica presente.
Las plataformas Drupal que el equipo de Drupal4edu de Drupart desarrolla para instituciones como la Universidad Yeditepe, la Universidad Istinye y la Universidad Medipol están configuradas para absorber estos picos exactamente de esta manera. Puede leer más sobre nuestro enfoque en la página Drupal en la educación superior.
Preguntas frecuentes sobre la velocidad de los sitios en Drupal
¿Un servidor más grande resolverá la lentitud?
Hasta cierto punto, pero es la vía más cara. La mayoría de las páginas que fallan en los días de mucha actividad se están reconstruyendo porque no pueden servirse desde una copia almacenada. Con la configuración de caché corregida, el mismo servidor atiende a muchos más visitantes. El orden sensato es revisar primero la configuración, hacer almacenable todo lo que no sea personal y solo entonces hablar de hardware si todavía no basta.
¿Basta con una CDN?
No. Una CDN distribuye imágenes, vídeos y fuentes, lo que reduce notablemente el peso de la página. Pero la página personal que ve un estudiante con sesión iniciada se construye igualmente en el propio servidor de la institución, y ahí es donde se concentra la carga en un día de mucha actividad. Considerar la CDN un complemento útil y no la solución principal lleva a un resultado más realista.
¿Se pueden almacenar datos en tiempo real, como las plazas disponibles?
Se pueden almacenar durante poco tiempo y, en la mayoría de los casos, conviene hacerlo. Un número de plazas con hasta un minuto de antigüedad suele ser aceptable, y ese minuto evita que miles de consultas lleguen al otro sistema. Lo importante es elegir esa vida útil de forma deliberada y acordarla con la secretaría académica. Igual de importante es que la página no aparezca vacía cuando el otro sistema no está disponible, sino que muestre la última cifra conocida con su marca de tiempo.
¿Hay que vaciar la caché después de cada cambio?
No, y es una costumbre que conviene abandonar. Drupal registra de qué contenido depende cada página almacenada, así que actualiza por sí solo las páginas afectadas cuando algo cambia. Vaciarlo todo obliga a reconstruir el sitio entero, y eso suele ocurrir en el momento de mayor actividad. Reserve ese botón para situaciones excepcionales en lugar de convertirlo en un reflejo diario.