Acelerar una web: qué determina el tamaño del trabajo
El tamaño del trabajo para acelerar una web depende de la causa de la lentitud. Qué fija su alcance y en qué orden conviene empezar.
Equipo de rabbitclipPublicación: 7 min. de lectura
En breve
El alcance de acelerar un sitio web depende del origen de la lentitud: los problemas de contenido, como imágenes y fuentes, se arreglan rápido, mientras que los problemas de servidor, de tema o de arquitectura del software suponen un trabajo mayor. El primer paso correcto no es, por tanto, ponerse a optimizar, sino medir de dónde viene la lentitud. Las mejoras hechas sin medir suelen consumir semanas y no cambiar nada.
Este artículo explica qué determina el tamaño del trabajo y en qué orden tiene sentido avanzar. Tenemos otro texto aparte sobre el detalle técnico de imágenes, fuentes y scripts; aquí la pregunta es distinta: ¿es este trabajo pequeño, mediano o grande, y por dónde debe empezar?
¿De dónde viene la lentitud?
El origen suele estar en uno de cuatro sitios. El primero es el contenido: imágenes demasiado grandes, muchos archivos de fuentes o vídeos pesados hinchan la página. El segundo es el código: scripts cargados sin necesidad, herramientas de seguimiento de terceros y código sin usar que arrastra un tema antiguo cansan al navegador.
El tercero es el servidor: un alojamiento lento, o una configuración sin caché, tiene que reconstruir cada página en cada visita. El cuarto es la arquitectura: el software sobre el que se construye el sitio puede ser pesado en sí mismo, o su forma de producir páginas puede ser ineficiente. Estas cuatro fuentes corresponden a cuatro niveles distintos de esfuerzo.
La mayoría de los sitios no tienen una sola causa; varias se acumulan. Normalmente, sin embargo, una predomina. La medición muestra cuál, y el trabajo empieza desde ahí.
¿Qué determina el tamaño del trabajo?
Tres factores fijan el tamaño. El primero es la capa del problema: los asuntos de la capa de contenido llevan horas o días, los del código días, y los de la arquitectura pueden llevar semanas. El segundo es el tamaño del sitio: en un sitio de cien páginas, incluso la limpieza de imágenes genera tanto trabajo como páginas hay.
El tercero es la flexibilidad del software subyacente. En un sitio cuyo código se puede trabajar libremente, las mejoras se hacen directamente; en una plataforma cerrada, lo que se puede cambiar es limitado y el resultado topa con un techo. La verdadera decisión es entonces si acelerar el sitio o cambiar de plataforma.
No damos cifras de coste ni de duración, porque el mismo síntoma de lentitud puede venir de causas muy distintas, y adivinar antes de mirar induce a error. Un paso de descubrimiento y medición hace visible el tamaño real del trabajo.
¿Qué debe medirse primero?
La medición es el primer paso de cualquier trabajo de velocidad. Destacan tres indicadores: cuánto tarda en aparecer el contenido principal de la página (LCP, umbral bueno de 2,5 segundos), con qué rapidez responde la página a la interacción del usuario (INP, umbral bueno de 200 milisegundos) y si los elementos saltan mientras carga (CLS, umbral bueno de 0,1). Estos umbrales están publicados y son ampliamente conocidos.
Medir solo en un ordenador de escritorio y en una sola página induce a error. Si la mayoría de los visitantes llegan desde un móvil, hay que medir en un móvil y con una conexión media, y mirar por separado la página de inicio y las páginas interiores más visitadas. También puede hacer una prueba de velocidad de su propio sitio con la herramienta gratuita de nuestra web.
Tras medir, los problemas se ordenan según su efecto: el punto que afecta a más páginas y que puede corregirse con menos esfuerzo va primero. Esta ordenación dirige el tiempo y el presupuesto al lugar más productivo.
¿En qué orden debe avanzar el trabajo?
Un orden sensato empieza por lo que aporta más ganancia con menos esfuerzo. Normalmente la primera ronda consiste en redimensionar las imágenes y convertirlas a formatos modernos, eliminar los scripts sin usar y configurar bien la caché. Estos pasos marcan una diferencia clara en la mayoría de los sitios y entrañan poco riesgo.
La segunda ronda exige más esfuerzo: simplificar las fuentes, adelantar el contenido crítico y reducir las herramientas de terceros a las que realmente se necesitan. La tercera ronda es estructural: un cambio de servidor, la simplificación del tema o la reescritura de partes del sitio. A esa ronda solo se entra si las dos primeras resultan insuficientes.
- Medir: registrar los valores clave en dispositivos y conexiones reales
- Reducir las imágenes y eliminar los scripts innecesarios
- Configurar bien la caché y la compresión
- Simplificar las fuentes y las herramientas de terceros
- Volver a medir; pasar al trabajo estructural solo si hace falta
¿Qué errores son frecuentes en el trabajo de velocidad?
El error más común es empezar sin medir. Instalar un complemento y esperar que suba la puntuación puede ocultar la causa real; la puntuación mejora un tiempo, pero la experiencia real de los visitantes no cambia. El segundo error es mirar solo la puntuación: un número de una herramienta de prueba no siempre refleja lo que viven los usuarios reales.
El tercer error es cambiarlo todo a la vez. Si se hacen varios cambios juntos, nadie puede saber cuál funcionó y cuál rompió algo. El cuarto es romper una función al acelerar: eliminar un script que resulta alimentar un formulario o una etiqueta de seguimiento cuesta más que la velocidad ganada. Tras cada cambio deben probarse a mano las funciones básicas.
La velocidad tampoco es un trabajo que se hace una vez. A medida que se añaden contenidos, complementos y herramientas de seguimiento nuevos, el sitio vuelve a ralentizarse. Por eso una rutina de revisiones periódicas da un resultado más duradero que un único gran esfuerzo.
¿Cuándo es acelerar la elección equivocada?
En algunos sitios el verdadero problema no es la velocidad. Si el mensaje no está claro, las páginas no ofrecen lo que los visitantes venían a buscar o el formulario no funciona, mejorar la velocidad no elevará las conversiones. Mire primero por qué se van los visitantes; la velocidad es solo una de las razones.
Si el software sobre el que funciona el sitio ha envejecido y acelerarlo se convierte en remendar unos cimientos podridos, una reconstrucción puede ser el camino más sensato. Un sitio que se remienda sin fin se vuelve más frágil con cada parche. En ese caso, un proyecto de velocidad significa gastar parte del presupuesto en la estructura antigua en lugar de en la nueva.
El tamaño de un trabajo de aceleración lo fija el origen de la lentitud, y solo la medición revela ese origen. Registre primero los valores clave en dispositivos reales, ordene los problemas según su efecto, empiece por pasos pequeños y de bajo riesgo y vuelva a medir después de cada uno. Si desea revisar juntos por qué su sitio es lento, estaremos encantados de concertar una conversación de descubrimiento con rabbitclip.
Preguntas frecuentes
¿Cuánto tarda acelerar una web?
Depende del origen de la lentitud y del tamaño del sitio. El trabajo con imágenes y scripts es rápido; lo que exige cambios de servidor o de arquitectura lleva más tiempo. No es posible dar una estimación fiable antes de medir.
Si la puntuación de una prueba de velocidad es alta, ¿el sitio es rápido?
No siempre. Una puntuación es un indicador; la experiencia real de los visitantes varía con el dispositivo y la conexión. Es más fiable probar en un móvil con una conexión media y comprobar el LCP, el INP y el CLS.
¿Basta un complemento para acelerar un sitio?
En algunos sitios los complementos de caché y compresión marcan una diferencia. Pero si el problema está en imágenes pesadas, demasiados scripts o el servidor, un complemento no lo resolverá por sí solo. Instalar uno antes de hallar la causa puede hacer perder tiempo.
¿La velocidad del sitio afecta de verdad a las ventas?
Un visitante puede abandonar una página lenta antes de que termine de cargar, lo que reduce la probabilidad de que se use el formulario o el proceso de compra. El tamaño del efecto varía de un sitio a otro y no puede fijarse con una cifra.
