Por motivos de confidencialidad, nos referiremos aquí a la organización como Festival Confluencia: un festival cultural de temporada, con web propia en WordPress alojada en un VPS que administramos nosotros mismos. Llevábamos ya un tiempo trabajando con ellos cuando empezó a llegar la misma queja, repetida por varias personas del equipo de comunicación: «la web va lenta». Nadie sabía decir en qué momento exacto ni en qué página — solo la sensación general de que algo no iba bien.
El punto de partida
«Lento» es la queja menos útil con la que se puede empezar a trabajar, porque puede significar media docena de cosas completamente distintas: un servidor que tarda en responder, una base de datos sin optimizar, un plugin mal configurado, o algo que no tiene nada que ver con el servidor y sí con lo que el navegador tiene que descargar después. Antes de tocar nada, había que medir — y medir significaba entrar de verdad en el servidor, no adivinar desde fuera.
Lo primero que miramos: el servidor, en directo
Con acceso directo al VPS por Plesk, lo primero fue una auditoría real contra el propio servidor: una petición curl directa a la web, cronometrando cada fase de la respuesta. El resultado fue un TTFB (el tiempo que tarda el servidor en empezar a responder) de 0,309 segundos — un dato bueno, no un síntoma de nada.
Comprobamos también que la compresión estaba funcionando de verdad a nivel de Apache: el módulo deflate (gzip) ya estaba activo por defecto en la configuración de Plesk, y aprovechamos para activar además brotli, que comprime algo mejor en los navegadores que lo soportan. El HTML de la home bajaba de 550 KB reales a 46 KB por la red — una compresión de casi el 92%. Revisamos también las cabeceras de seguridad (CSP, HSTS) y estaban correctamente configuradas, y confirmamos que OPcache, el caché de bytecode de PHP, ya estaba activo en la versión de PHP del servidor.
Con esos números delante, la conclusión fue clara: el servidor no era el problema. Y sin embargo la queja seguía siendo real — la gente notaba algo, y ese algo no estaba mintiendo.
Donde de verdad estaba el problema
El siguiente paso fue dejar de mirar el servidor y mirar lo que el navegador hacía después de recibir su respuesta. Con la pestaña de red de las herramientas de desarrollador abierta mientras cargaba la home, apareció el patrón enseguida: un vídeo de fondo alojado en Vimeo que descargaba continuamente fragmentos de varios megabytes, en bucle, por el propio funcionamiento del streaming adaptativo. Cada visita a la home estaba tirando de un tráfico constante que no tenía nada que ver con el HTML, el servidor ni la compresión que acabábamos de verificar.
De paso, revisando la configuración de seguridad del dominio en Plesk, encontramos algo que no era la causa principal pero sí un fallo real: la Content-Security-Policy del sitio no tenía Vimeo incluido en su directiva frame-src, lo que en ciertas condiciones podía bloquear directamente el embed del vídeo en vez de solo cargarlo lento. Lo corregimos ahí mismo, añadiendo Vimeo a la política, para que ese no fuera un segundo problema sumado al primero.
La causa raíz: dos hubs de Híbrida trabajando en el mismo caso
Aquí el caso deja de ser solo un problema de servidor y empieza a cruzar dos frentes de Híbrida a la vez. El material en bruto lo había entregado la organización a calidad completa, tal cual salido de cámara — pesado, sin corregir. Desde ACMEDIA, el hub de producción audiovisual de Híbrida, se hizo el trabajo de postproducción real: corrección de color, mejora de sonido y una exportación final en DaVinci Resolve pensada específicamente para uso web, con el peso y la resolución ajustados para un vídeo de fondo, no para proyección.
El problema fue de gestión de archivos, no de producción: el vídeo que terminó subido a Vimeo fue el material en bruto original, no la exportación ya trabajada por ACMEDIA. Dos versiones del mismo vídeo — una lista para publicarse, otra no — y la que quedó publicada en la web fue la que no debía.
Antes de dar el problema por cerrado, quisimos confirmar que la caché de WordPress estaba haciendo su trabajo, porque en las primeras pruebas parecía fallar: las cabeceras devolvían MISS o BYPASS en vez de HIT. Revisando con calma, la explicación no era que la caché no funcionara, sino que estábamos haciendo las pruebas con sesión de WordPress abierta en el propio navegador — y por diseño, la caché no sirve contenido cacheado a un usuario logueado. En cuanto probamos desde un navegador limpio, sin sesión, el X-Cache-Status devolvió STALE, confirmando que la caché sí estaba activa y sirviendo contenido real. Un falso negativo que, de no comprobarlo bien, habría hecho perder tiempo revisando un sistema que no tenía ningún fallo.
Para medir el impacto real del vídeo pesado con datos objetivos y no solo con la pestaña de red, corrimos PageSpeed Insights simulando una conexión móvil 4G lenta. El resultado: rendimiento de 57 sobre 100, y un LCP (el tiempo hasta que se pinta el contenido principal en pantalla) de 14,2 segundos. Google marca como «bueno» un LCP de hasta 2,5 segundos, y como «deficiente» a partir de 4 — 14,2 segundos es casi 3,5 veces ese umbral de «deficiente», no un simple matiz de rendimiento. El propio reproductor de Vimeo llegó a mostrar un error de carga visible durante esa simulación, confirmando sin ambigüedad de dónde venía el problema.
Los ajustes que se hicieron
Sustituimos el vídeo por la versión ligera correcta, con resolución reducida — de sobra para su función decorativa de fondo, donde no hace falta calidad de proyección, solo ambientación visual. Dejamos la directiva CSP corregida con Vimeo permitido en frame-src. Y confirmamos, con pruebas limpias sin sesión, que la caché quedaba sirviendo contenido cacheado de verdad para cualquier visitante nuevo.
El resultado
El TTFB nunca cambió, porque nunca fue el problema — seguía en los mismos 0,309 segundos que el primer día. Lo que sí cambió fue el peso real que el navegador de cada visitante tenía que descargar para ver la home completa, y con ello, la sensación de lentitud que llevaba semanas reportándose desapareció.
Por qué lo contamos
Es fácil dar por hecho que «la web va lenta» significa «el servidor va lento», y lanzarse a optimizar lo primero que se tiene a mano. Aquí el servidor respondía perfectamente — TTFB bueno, compresión activa, caché funcionando — y aun así había un problema real, solo que estaba en otro sitio: un archivo de vídeo mal subido y una directiva de seguridad que necesitaba un ajuste. Entrar de verdad en el servidor a medir, en vez de adivinar desde fuera, es lo que permite distinguir entre lo que ya funciona bien y lo que de verdad hay que arreglar — y no perder tiempo revisando sistemas, como la caché en este caso, que en realidad no tenían ningún fallo.
Y también lo contamos porque este caso no lo resolvió un solo frente de Híbrida. El diagnóstico de servidor (TTFB, compresión, CSP, caché) es trabajo de infraestructura de B2A; la corrección de color, sonido y exportación optimizada del vídeo es trabajo de ACMEDIA. La solución final no salió de arreglar el servidor ni de reeditar el vídeo por separado, sino de que ambos frentes trabajaran sobre el mismo problema con el mismo criterio técnico — que es, en el fondo, la idea de tener varios hubs bajo un único paraguas en vez de contratar proveedores sueltos que no se hablan entre sí.
