El coste oculto de las webs sobrecargadas, desde acordeones con Alpine.js hasta sliders con Swiper. Menos dependencias significan un sitio más rápido y fácil de mantener.
Últimamente me he dedicado a arreglar sitios web de Webflow hechos por otros.
No a crearlos desde cero, sino a rescatarlos. Cuatro sitios en las últimas semanas, cada uno de un desarrollador distinto. Y en los cuatro encontré lo mismo: librerías sobre librerías, scripts de terceros para funciones que Webflow ya gestiona de forma nativa y dependencias justificadas solo por costumbre.
Los sitios se veían bien, pero bajo el capó cargaban un peso enorme e innecesario.
Si tu sitio Webflow es lento, difícil de mantener o tiene una mala puntuación en las auditorías de rendimiento, probablemente sea por esto.
Cómo es realmente el exceso de dependencias
Veo este patrón constantemente: un desarrollador añade Alpine.js para un simple acordeón, incorpora Swiper.js para un slider básico y usa una librería externa para un tooltip que podría hacerse con diez líneas de JavaScript nativo.
Cada decisión parece razonable por separado. Alpine es ligero, Swiper es popular. Son herramientas consolidadas con buena documentación.
El problema no es una librería concreta, sino la acumulación.
Cada script externo que carga tu sitio es una petición a un servidor ajeno. Cada petición añade latencia. Cada librería suma kilobytes —a veces cientos— a la carga que el navegador del usuario debe descargar, procesar y ejecutar antes de que la página sea funcional.
Y esto es antes de añadir una sola dependencia empresarial legítima.
La carga real
Hablemos de lo que realmente necesita cargar un sitio web empresarial típico:
- Integración CRM — HubSpot, Salesforce, Pipedrive. Esencial. Pesado.
- Email marketing — Mailchimp, Klaviyo. Esencial. Más peso.
- Analítica — Google Analytics, GA4. Estándar. Más peticiones.
- Grabación de sesiones — Hotjar, Microsoft Clarity. Útil. Sobrecarga significativa.
- Chat en vivo — Intercom, Drift. Otro script. Otro retraso.
- Consentimiento de cookies — exigido por ley. Otra dependencia más.
Esta es la base para la mayoría de los sitios web de marketing. Ya supone una carga considerable, y cada una de estas herramientas está justificada.
Ahora añade Alpine para un acordeón. Swiper para un carrusel. Un framework CSS para algunas utilidades de diseño que el desarrollador no quiso escribir manualmente.
Acabas de pasar de una carga razonable a un problema de rendimiento. Y tus visitantes —aquellos por los que estás pagando para atraerlos— son quienes lo sufren.
Por qué tres segundos es la cifra que debes conocer
La investigación de Google es clara: a medida que el tiempo de carga de una página aumenta de un segundo a tres, la probabilidad de que un visitante abandone el sitio aumenta un 32%. A los cinco segundos, esa cifra salta al 90%.
Tres segundos. Ese es el umbral en el que empiezas a perder gente; personas que hicieron clic en un anuncio, siguieron un enlace, buscaron lo que ofreces y llegaron con una intención real. No decidieron que tu servicio no era para ellos. Es que tu sitio web no cargó lo suficientemente rápido.
Para las empresas que invierten en captación de pago, esto supone un coste directo y medible. Cada punto porcentual de aumento en la tasa de rebote es dinero invertido en llevar a alguien a una puerta que no se abrió a tiempo.
El rendimiento no es una métrica de vanidad técnica. Es una variable de ingresos.
Webflow ya hace la mayor parte de esto
Esto es lo que me frustra de las dependencias de librerías innecesarias en Webflow específicamente: la plataforma ha evolucionado significativamente. La mayoría de las cosas para las que los desarrolladores recurren a librerías externas, Webflow las maneja de forma nativa, o pueden hacerse limpiamente con una pequeña cantidad de JavaScript personalizado.
¿Acordeones? Interacciones nativas. No hace falta Alpine.
¿Deslizadores y carruseles? El componente deslizador nativo de Webflow cubre la gran mayoría de los casos de uso. Para cualquier cosa más compleja, unas pocas líneas de JS estándar serán suficientes.
¿Animaciones activadas por scroll? El motor de animaciones de Webflow es realmente potente. La mayoría de los efectos de scroll —desvanecimientos, paralaje, contadores, revelaciones— pueden construirse sin tocar ni una sola librería externa.
Los desarrolladores que veo recurriendo a estas herramientas no lo hacen porque Webflow no pueda manejarlo. Lo hacen porque aprendieron una herramienta concreta y recurren a ella por defecto. Es un problema de hábitos, no de capacidad.
Cuándo están realmente justificadas las librerías externas
Para que quede claro: esto no es un argumento en contra de usar librerías externas. Algunas realmente merecen la pena.
GSAP (GreenSock Animation Platform) es la que elegiría cuando un proyecto exige animaciones sofisticadas basadas en líneas de tiempo. Es eficiente, está bien mantenida y hace cosas que el motor nativo de Webflow no puede igualar en secuencias complejas. Si un proyecto lo requiere, merece la pena.
Three.js para experiencias WebGL. Si estás construyendo algo que realmente necesita renderizado 3D, Three.js es la herramienta adecuada. Es una carga considerable, pero también lo es lo que permite hacer.
La pregunta que hay que hacerse con cada dependencia externa es sencilla: ¿hace esto algo que realmente no pueda hacer de otra manera? ¿Y merece la pena el coste en rendimiento? Si la respuesta a ambas partes es sí, cárgala. Si no, no lo hagas.
The developers I've been cleaning up after weren't asking that question. They were defaulting.
What This Means If You Own the Website
If you're a CMO, marketing director, or founder responsible for a Webflow site built by an agency or freelancer, here's what's worth checking:
Run a performance audit. Google PageSpeed Insights is free and takes thirty seconds. If your mobile score is below 70, something is wrong. Below 50, something is significantly wrong.
Ask about third-party scripts. Request a list of every external script loading on your site. Ask what each one does and why it's there. If the developer can't explain the business justification for a library, it probably shouldn't be there.
Don't conflate features with performance. A site that does lots of impressive things slowly is worse, commercially, than a site that does the right things fast. Animation and interactivity are valuable — but not at the cost of the three seconds that determine whether anyone stays to see them.
The Maintenance Problem Nobody Mentions
There's a second cost to dependency bloat that shows up later: maintenance.
External libraries release updates. Some updates introduce breaking changes. A site dependent on five third-party libraries is five points of potential failure with every update cycle. A site that does the same things natively or with minimal custom code has one: Webflow itself.
I've spent hours on rescue projects unpicking problems caused by version conflicts between libraries that have no business being on the same site. It's expensive, frustrating, and entirely avoidable.
Build lean. Maintain less. Your future self — or the next developer who touches the site — will thank you.