45 plugins, 12 GB y una web que pedía socorro

Una web bonita. Diseño moderno, tipografía bien escogida, identidad visual coherente, hecha por una empresa con buena reputación en el sector. Hasta ahí, todo correcto. Hasta ahí, todo lo que se le pide a un encargo profesional. Y entonces uno entra al panel de administración y se encuentra con 45 plugins instalados y 12 GB de espacio ocupados en el hosting. De esos 12 GB, las imágenes, los PDFs y todo lo que normalmente engorda una web no llegan ni a 2 GB. El otro 80% es relleno. Es ruido. Es, llamémoslo por su nombre, basura digital.

El cliente, lógicamente, se queja de que la web va lenta y pesada. Y la solución que le habían planteado antes de llegar a mí era la previsible: contratar a alguien que se ocupe de optimizar el rendimiento. Es decir, contratar a una segunda persona para arreglar lo que la primera, supuestamente, ya tendría que haber dejado bien hecho desde el principio. Esto, lejos de ser un caso aislado, se está convirtiendo en norma. Y conviene hablarlo.

El delirio de los 45 plugins

Vamos por partes, porque la cifra impresiona pero no se entiende del todo si uno no está metido en el barro de WordPress. Una web corporativa estándar, con su página de inicio, sus servicios, su blog, su formulario de contacto y sus avisos legales, puede funcionar perfectamente con seis u ocho plugins bien escogidos. A veces incluso con menos. Pasar de ahí ya empieza a oler raro. Llegar a 45 es directamente síntoma de que nadie ha tomado decisiones en mucho tiempo: simplemente se ha ido instalando lo que iba haciendo falta sin quitar nunca nada y sin preguntarse si lo nuevo solapaba con lo viejo.

En esa web concreta había, por ejemplo, tres plugins distintos relacionados con SEO. Dos plugins de seguridad. Cuatro extensiones de un mismo page builder, dos de las cuales hacían exactamente lo mismo. Un plugin de redes sociales que llevaba dos años sin actualizarse y que ya nadie usaba. Un complemento para mostrar avisos de cookies que coexistía con el banner del propio CMS. Y un par de herramientas de mantenimiento que los desarrolladores originales debieron de instalar para algo puntual y que se quedaron ahí, ejecutándose en cada carga de página, consumiendo memoria y haciendo consultas a la base de datos sin que nadie supiese ya muy bien para qué.

Cada uno de esos plugins, por separado, es probablemente decente. El problema no son ellos. El problema es la acumulación. Cada plugin añade su propio CSS, su propio JavaScript, sus propias entradas en la base de datos, sus propias tareas programadas y, muchas veces, su propio sistema de actualización automática que se ejecuta en segundo plano. Multiplica eso por 45 y tienes un servidor trabajando a destajo para servir una web que, en realidad, podría correr con la quinta parte del esfuerzo.

Copias de copias de copias: el síndrome del "por si acaso"

El otro gran sospechoso de los 12 GB son los sistemas de respaldo. En esta web había un plugin de copias de seguridad configurado para hacer un backup completo cada noche y guardarlo en el propio servidor. Eso, en sí mismo, ya es una mala idea —si el servidor revienta, la copia revienta con él—, pero se podría aceptar como medida básica si fuese la única. La gracia es que el hosting, por su cuenta, también hacía sus propias copias de seguridad diarias del servidor entero. Y por encima de eso, había un segundo plugin más antiguo, olvidado, que también guardaba sus propios respaldos en otra carpeta.

Resultado: tres juegos de copias de seguridad superpuestos, casi todos almacenados en el mismo sitio físico, con políticas de retención diferentes y sin que nadie supiera muy bien cuál era el bueno. La carpeta más antigua tenía respaldos de 2021 que llevaban ahí cuatro años, ocupando varios gigas, sin que nadie los hubiera abierto jamás. Y al lado, otra carpeta con cachés de optimización que, con el paso del tiempo y los cambios de plugin, se habían vuelto basura inservible que el sistema seguía leyendo en cada petición.

Todo esto pasa porque el modelo mental por defecto en muchos proyectos web es el "por si acaso". Por si acaso, dejamos otro plugin de copias. Por si acaso, no borramos los respaldos viejos. Por si acaso, instalamos también otra caché distinta. El "por si acaso" parece prudente, pero en realidad es lo contrario: es trasladar al cliente —y al servidor, y al planeta— el coste de no haber tomado decisiones a tiempo. Es delegar la responsabilidad en la acumulación.

La trampa de los page builders y el código de relleno

Y luego está el otro gran capítulo de la basura digital contemporánea: los maquetadores visuales. Los page builders. Esas herramientas que prometen hacer webs preciosas sin tocar una línea de código y que, por debajo, generan un HTML que da pena. Etiquetas anidadas siete y ocho niveles, divs dentro de divs dentro de divs, atributos repetidos, hojas de estilo de varios megas para definir cosas que se podrían escribir en treinta líneas de CSS bien pensadas. Un párrafo de texto que en HTML limpio cabe en una etiqueta de seis caracteres puede acabar envuelto en cuatro contenedores con identificadores únicos, clases de utilidad y atributos personalizados.

Cuando el navegador del visitante recibe todo eso, tiene que hacer un trabajo enorme antes de pintar nada en pantalla. Descargar más kilobytes, parsear más HTML, ejecutar más JavaScript, calcular más estilos. Y, al otro lado, el servidor que sirve la web tiene que generar todo ese código en cada visita, ejecutar todos los plugins relacionados, mover toda esa información por la red. La sensación de lentitud que percibe el cliente cuando dice "la web va pesada" no es subjetiva: es la consecuencia matemática de que se está moviendo mucha más información de la que haría falta para mostrar exactamente lo mismo.

Lo más triste es que muchas de las webs hechas con page builders se podrían reescribir en HTML y CSS limpios sin perder absolutamente nada visualmente. El mismo diseño, la misma identidad, las mismas animaciones. Pero pesando una décima parte y cargando en una fracción del tiempo. Lo que ocurre es que esa reescritura cuesta horas de trabajo cualificado, y montar la web encima de un constructor visual cuesta menos. El sobrecoste del trabajo bien hecho se traslada a otra parte: al hosting, al consumo eléctrico, a la paciencia del visitante.

Optimizar una web es como optimizar materiales en arquitectura

Aquí es donde a mí me gusta tirar de la metáfora arquitectónica, porque creo que ayuda a entenderlo. En arquitectura, la optimización de materiales es uno de los grandes asuntos del oficio. No solo por dinero, también por cálculo estructural, por durabilidad y, cada vez más, por sostenibilidad. Un edificio bien diseñado usa exactamente la cantidad de hormigón, acero o madera que necesita. Ni un kilo más. Cada elemento tiene una función, cada material está donde tiene que estar y todo lo que sobra se considera un fallo de diseño, no un detalle.

En 1908 Adolf Loos publicó un texto provocador titulado Ornamento y delito en el que sostenía que la decoración superflua era literalmente un crimen contra el tiempo, los recursos y el trabajo humano. Hoy nos parece exagerado, pero en el fondo tenía razón en algo: cada pieza añadida sin función real es una factura que alguien tiene que pagar, ya sea el cliente, el constructor o las generaciones futuras. La modernidad arquitectónica, con todas sus contradicciones, se construyó sobre esa idea. Mies van der Rohe lo convirtió en eslogan: less is more.

La web actual va exactamente en sentido contrario. Acumulamos plugins como si fueran molduras barrocas. Instalamos page builders que son la equivalencia digital del estuco falso pegado encima del ladrillo. Generamos código redundante con la naturalidad con la que un palacete decimonónico se llenaba de cariátides. Y luego nos sorprendemos de que la web vaya lenta. Si un edificio se cayese cada vez que sumamos un balcón decorativo de más, hace mucho que habríamos cambiado de método.

La factura energética que nadie ve

Toda esta basura digital tiene un coste muy concreto que la mayoría de las veces no aparece en ninguna conversación con el cliente: el coste energético. Cada visita a una web pesada consume más electricidad que la misma visita a una web ligera. Esto no es teoría, es física. El servidor trabaja más, los routers intermedios mueven más datos, el dispositivo del visitante gasta más batería procesando contenido innecesario. Multiplica eso por miles de visitas al mes, por millones de webs en el mundo, y obtienes una de las industrias que más rápido está creciendo en consumo eléctrico mundial.

Los centros de datos representan ya un porcentaje nada despreciable del consumo energético global, y la curva no para de crecer. Una parte de ese crecimiento es inevitable y razonable: necesitamos más servicios digitales, más almacenamiento, más capacidad de cómputo. Pero otra parte —y aquí está lo doloroso— es directamente desperdicio. Es servidores trabajando para mover plugins duplicados. Es discos llenándose de copias de seguridad de copias de seguridad. Es navegadores de millones de usuarios renderizando código basura que se podría haber escrito mejor. Cada vez que alguien instala un plugin innecesario está, en una proporción microscópica pero real, contribuyendo a que en algún sitio del mundo haya que construir un centro de datos un poco más grande.

Esto no es alarmismo verde de boquilla. Es contabilidad básica de recursos. La huella de carbono de una web optimizada y la de una web no optimizada pueden diferir en un orden de magnitud para servir exactamente el mismo contenido. Y como nadie ve esa factura —no llega al cliente, no llega al diseñador, no llega al usuario—, sencillamente nadie la paga atendiéndola. La pagamos todos, en diferido, en forma de servidores sobredimensionados, refrigeración industrial y emisiones que perfectamente podríamos habernos ahorrado.

Tomar conciencia y hacer las cosas con cabeza

El caso del cliente con sus 45 plugins se resolvió como suelen resolverse estas cosas: con paciencia, con un análisis honesto de qué hacía falta y qué no, y con un trabajo de limpieza que llevó bastantes horas. Se fueron por el desagüe veintitantos plugins, se reorganizaron las copias de seguridad, se desactivaron procesos que llevaban meses ejecutándose en vano, se borraron varios gigas de cachés inservibles. La web pasó a ocupar menos de la mitad y a cargar bastante más rápido, sin tocar ni una coma del diseño visible. El cliente quedó contento. Pero esa solución, hecha a posteriori, costó dinero y tiempo que no habrían sido necesarios si las cosas se hubieran hecho con cabeza desde el principio.

Y este es, creo, el punto que conviene asumir colectivamente. La optimización web no es un servicio extra que se contrata cuando algo va mal. Es parte del oficio. Igual que en arquitectura no se entrega un edificio mal calculado y luego se contrata a otro estudio para que lo apuntale, en desarrollo web tampoco debería entregarse una página inflada para luego pagar a alguien que la deshinche. Hacer una web ligera, limpia y eficiente desde el primer día es perfectamente posible. Existen las herramientas, existen los conocimientos, existen los profesionales que saben hacerlo. Lo único que falta, muchas veces, es la decisión de tomárselo en serio.

Esto pasa por elegir el menor número posible de plugins, por preferir soluciones que escriban código limpio en lugar de soluciones que lo pesen, por configurar las copias de seguridad en un único sistema y no en tres a la vez, por no instalar cachés sobre cachés, y sobre todo por entender que cada elemento añadido tiene un coste que va más allá de la tarifa del plugin o del tema. Tiene un coste de tiempo de carga, un coste de mantenimiento futuro, un coste energético y un coste ambiental. Cuando se mira así, la pregunta deja de ser "¿qué le añadimos a la web?" y pasa a ser "¿qué hace falta de verdad para que esta web funcione bien?". Que es una pregunta mucho más honesta y mucho más sostenible. Aunque, eso sí, mucho menos rentable a corto plazo para quien factura por plugins instalados.