Respuesta breve
La velocidad de un sitio suele reducirse a cuatro cosas: imágenes, tipografías web, scripts de terceros y trabajo que bloquea el renderizado. Vemos qué hace cada capa, cómo medir un cambio sin engañarse y cuánto cuesta una corrección puntual.
La respuesta corta: qué decide de verdad la velocidad de una página: Cuatro capas deciden la velocidad de una página:…
La velocidad de una página depende de cuatro cosas que se pueden señalar con el dedo: imágenes que cargan más datos de los que el diseño necesita, tipografías que retrasan el texto, scripts de terceros añadidos para analítica y chat, y el trabajo que bloquea el renderizado.
Lo demás — alojamiento, caché, protocolo, base de datos — también influye, pero pertenece a una segunda capa de la conversación. Primero conviene mirar qué descarga la página y en qué orden, y después de dónde saca esos archivos y con qué rapidez responde el servidor.
Para quien está decidiendo si contratar a alguien, eso es una buena noticia. La lista es corta y comprobable. No hace falta entender cómo funciona un navegador para plantear cuatro preguntas concretas y notar si las respuestas están hechas de datos o de tranquilidad.
Las secciones siguientes recorren cada capa: qué ocurre, por qué lo nota quien visita, qué se suele hacer al respecto y dónde termina la responsabilidad de quien desarrolla. Los puntos técnicos siguen la documentación de rendimiento de MDN y las pautas del W3C enlazadas al final.
La velocidad como sensación: qué nota realmente quien visita
Quien visita no cuenta milisegundos. Registra tres momentos: cuando aparece algo en la pantalla, cuando aparece aquello que venía a buscar — un titular, un precio, una foto de producto — y cuando la página empieza a responder a los toques.
MDN lo trata como rendimiento percibido: la sensación de rapidez depende de qué se muestra y en qué orden, no solo del tiempo total de carga. Una página puede tardar más en conjunto y aun así sentirse más ágil si entrega significado en porciones útiles.
La consecuencia práctica es que se optimiza el camino hasta la primera pantalla útil, no un promedio en un informe. Cuando la oferta por la que alguien entró aparece la última, acelerar todo lo demás cambia una cifra sin cambiar la experiencia.
Lo contrario también se cumple. Una página que pinta el texto al instante pero ignora un toque durante un segundo se siente rota. La capacidad de respuesta forma parte de la velocidad y se apoya en mantener libre el hilo principal, no en el tamaño de las fotos.
Imágenes: peso, dimensiones y formato
Con las imágenes el fallo suele ser el mismo. Se coloca en el diseño un archivo en su resolución original y se muestra a una fracción de ese tamaño. El navegador lo descarga entero y luego reduce el resultado: se pagan bytes que nadie llega a ver.
Tres hábitos lo corrigen. Servir varios tamaños con srcset y sizes para que un móvil reciba una versión de móvil. Usar formatos actuales como WebP o AVIF donde haya soporte. Y exportar a las dimensiones que el contenedor necesita en lugar de confiar en que el CSS lo encoja.
La carga diferida merece una frase propia. El atributo loading="lazy" encaja con las imágenes por debajo del primer pliegue, pero no con la de arriba de la página: si la difieres, difieres justo el momento por el que esa persona abrió la página.
Y conviene declarar siempre ancho y alto, o una relación de aspecto. Eso no tiene que ver con el peso del archivo, sino con permitir que el navegador reserve el espacio por adelantado y el texto no salte cuando la imagen por fin llegue.
Tipografías: por qué el texto no aparece de inmediato
El navegador no descubre una tipografía web de inmediato. Primero tiene que recibir y analizar el CSS, y solo entonces sabe qué archivo de fuente pedir. Por eso el texto compuesto con una fuente enlazada suele llegar más tarde que el marcado que lo rodea.
Lo que ocurre en ese hueco lo decide font-display. Con el valor por defecto, el navegador puede mantener el texto invisible mientras espera. El valor swap le indica que muestre de inmediato una fuente del sistema y sustituya después: quien lee recibe las palabras antes que el estilo.
Después está el volumen. Un sitio no necesita un archivo con todos los alfabetos; reducirlo a los caracteres que realmente se usan recorta peso real. Una fuente variable puede sustituir a tres o cuatro pesos estáticos, y precargar un archivo crítico quita la pausa en un titular.
El precio de la sustitución es un salto en el momento en que llega la fuente definitiva. Se reduce eligiendo una alternativa con métricas parecidas. Es un compromiso, no un defecto: hay que elegir entre texto invisible y texto que se desplaza un poco.
Scripts de terceros: analítica, chat, píxeles y widgets
Analítica, píxeles publicitarios, un chat de soporte, un mapa, un widget de reseñas, un gestor de etiquetas. Cada uno añade una conexión con el dominio de otra empresa y código que se ejecuta en el mismo hilo principal que tu propia interfaz.
La dificultad no es que existan, sino que no los controlas. Su tamaño y su comportamiento los fija el proveedor que los publica, y un cambio hecho en su lado se convierte en un problema de tu página ese mismo día.
Conviene mantener un inventario: qué está cargado, quién lo pidió y qué devuelve. Los scripts sin responsable dentro de la empresa suelen ser restos de una campaña que terminó hace un año, y retirarlos no necesita una discusión larga.
Lo que se quede puede diferirse. Carga el chat y el mapa con una acción de la persona, no al abrir la página. Un botón «Escríbenos» que trae su widget solo después del clic cuesta menos que un widget servido a todo el que entra.
Trabajo que bloquea el renderizado: CSS y JavaScript síncrono
Antes de pintar nada, el navegador tiene que construir el árbol de estilos. Por eso las hojas de estilo del head bloquean el renderizado: hasta que se reciben y se analizan, la página sigue en blanco aunque el HTML haya llegado completo.
Los scripts se comportan de forma parecida, pero más estricta. Una etiqueta script normal detiene el análisis del HTML mientras se descarga y se ejecuta. El atributo defer traslada la ejecución a después del análisis y conserva el orden; async ejecuta cada archivo en cuanto está listo, sin orden garantizado.
Algunos estilos pueden salir de la ruta crítica con el atributo media: los de impresión o los de un punto de ruptura estrecho no tienen por qué retener la primera pantalla. El resto es cuestión de volumen, porque una sola hoja para todo el sitio obliga a cada página a esperar reglas que nunca usará.
Es la capa que nadie puede juzgar desde fuera y que casi cualquiera puede mejorar desde dentro. Cuando la única respuesta de un proveedor sobre velocidad es «comprimimos las imágenes», no ha mirado qué hay entre la petición y el primer píxel.
Desplazamientos del diseño: la página que salta bajo el dedo
Una página que salta no es un asunto cosmético. Alguien va a pulsar un botón, encima termina de cargarse un banner y el dedo aterriza en otro sitio. Es un fallo de interfaz, y se recuerda con más nitidez que un segundo de espera.
Las causas son previsibles: imágenes e incrustaciones sin dimensiones declaradas, anuncios de altura variable, un cambio de tipografía con métricas distintas y contenido insertado encima de lo que ya se veía. En todos los casos, la solución es reservar el espacio antes.
Aquí la velocidad se cruza con la accesibilidad. La referencia rápida del W3C para WCAG 2.2 incluye Reflow (1.4.10), que pide que el contenido siga siendo utilizable con zoom o en una pantalla estrecha, y Pause, Stop, Hide (2.2.2) para el contenido en movimiento.
El principio compartido es la previsibilidad. Reservar espacio para los medios y contener las animaciones automáticas mejoran a la vez la sensación de rapidez y la accesibilidad de la página: un caso poco frecuente en el que una sola corrección resuelve dos requisitos.
Qué aporta el servidor: caché, compresión y tiempo hasta el primer byte
El lado del servidor gobierna el tiempo hasta el primer byte: cuánto tarda el backend en componer una respuesta. Una consulta lenta a la base de datos, un renderizado completo en cada visita, la ausencia de caché: todo eso retrasa el momento en que el navegador tiene algo con lo que trabajar.
Después viene la entrega. Compresión de las respuestas de texto, cabeceras de caché para archivos estáticos con nombres versionados, distribución desde una red más cercana a quien visita. Son decisiones de configuración, no reescrituras, y suelen resolverse rápido.
Los protocolos actuales eliminan parte de la cola: HTTP/2 y HTTP/3 llevan muchas peticiones por una sola conexión. Eso no justifica descargar más de lo necesario; simplemente retira una parte de la espera que antes generaban las propias peticiones.
Conviene no mezclar las capas. Un servidor rápido no salva a una página que arrastra diez scripts de terceros, y un frontend bien construido no ayuda si la respuesta tarda dos segundos en aparecer. Hay que mirar los dos extremos.
Móviles y redes: dónde ocurre la prueba honesta
Quien desarrolla ve el sitio con conexión por cable, en una máquina potente y con todo ya en caché. Quien visita llega desde un móvil de gama media, por red móvil y por primera vez. Son dos sitios distintos, y el que cuenta es el segundo.
La diferencia no es solo de ancho de banda. Un procesador más débil tarda más en ejecutar el mismo JavaScript, más en analizar el CSS y más en decodificar imágenes. Lo que en un portátil pasa desapercibido, en un móvil se convierte en una pausa antes de responder a un toque.
Por eso conviene probar en un dispositivo real y con caché fría: una ventana privada, la limitación de red activada y una visita de vuelta unas horas después. La emulación de dispositivos de las herramientas de desarrollo sirve, pero modela las condiciones en lugar de reproducirlas.
Otro hábito: mirar la dispersión y no el promedio. Si la página abre de forma aceptable para mucha gente y bastante peor para una parte, la pregunta útil es quiénes son: qué gama de dispositivo, qué región, qué sección del sitio.
Cómo medir sin engañarse
Hay dos tipos de datos. Los de laboratorio salen de una ejecución controlada: repetibles, útiles para comparar antes y después, pero con las condiciones que tú elegiste. Los de campo son lo que de verdad les ocurrió a las visitas: más ruidosos y marcados por sus propios dispositivos.
MDN documenta las interfaces de medición del navegador — desde el navigation timing hasta PerformanceObserver — que permiten a la página registrar cuándo ocurrieron los eventos relevantes. En eso se apoyan los datos de campo: la medida se toma donde está sentada la persona.
El orden de trabajo es sencillo. Registra una línea base antes de cualquier cambio, en las mismas páginas y en las mismas condiciones. Cambia una capa cada vez. Vuelve a medir. De lo contrario tendrás una mejora sin saber qué la produjo.
Y acuerda de antemano qué cuenta como resultado. «Se nota más rápido» no es un criterio de aceptación. Una lista de cambios, páginas nombradas, un procedimiento de medición repetible y una comparación antes/después que pueda leer una tercera persona, sí lo es.
Cuánto cuesta el trabajo de velocidad en VITON13
Cuando el problema es local — imágenes pesadas, scripts olvidados, una tipografía sin alternativa — encaja el Site Fix Pack por $70: hasta 5 correcciones acordadas, revisión en móvil y escritorio, una lista de antes/después en la entrega, 1 ronda de revisiones y un plazo de 1-2 días laborables.
El Site Fix Pack excluye deliberadamente páginas nuevas, rediseño y migraciones. Es una herramienta para trabajo puntual. Si el diagnóstico muestra que la lentitud está en la estructura del sitio, la conversación pasa a construirlo de nuevo en lugar de parchearlo.
Ahí entra Sitio para lanzamiento por $380: maquetación adaptable, conexión de un CMS básico o de los datos y configuración del despliegue, en 3-5 días laborables y con 2 rondas de revisiones antes del lanzamiento. El contenido y las traducciones los aporta el cliente, porque nosotros no los escribimos.
Cuando la velocidad debe mantenerse después, está el Soporte técnico continuo por $290/mes: actualizaciones prioritarias, un ritmo semanal de publicaciones y mantenimiento técnico. Funciona por ciclo mensual, el volumen se acuerda al principio de cada ciclo y se detiene avisando con 30 días.
Límites: dónde la velocidad deja de ser la respuesta
La velocidad retira un obstáculo; no crea demanda. Si la página no explica qué vendes y por qué vale su precio, una carga instantánea solo mostrará antes el texto que no convence a quien lo lee.
Algunos límites son externos. Un reproductor incrustado, un formulario de pago, el widget de reservas de un socio: controlas cuándo se cargan, no cuánto pesan. A veces la respuesta honesta es cambiar de proveedor en lugar de optimizar su código.
Otros límites son nuestros y conviene conocerlos de antemano. VITON13 no escribe el contenido ni las traducciones del cliente, y no desarrolla aplicaciones móviles nativas. Si la tarea es esa, corresponde a otro proveedor o a otro contrato.
Por último, el trabajo de velocidad nunca es un acto único. Cada campaña añade un script y cada página nueva añade imágenes. Conviene acordar no solo las correcciones de ahora, sino también quién vigila la página después y con qué ritmo lo hace.
Lista práctica
- Enumera todos los scripts de terceros del sitio y asigna un responsable a cada uno.
- Sirve las imágenes en varios tamaños y en un formato actual.
- Declara ancho y alto, o una relación de aspecto, en cada imagen y en cada incrustación.
- Comprueba que las tipografías enlazadas usan font-display: swap y están reducidas a los caracteres necesarios.
- Saca de la ruta crítica los estilos y scripts de los que la primera pantalla puede prescindir.
- Mide antes y después de los cambios, en las mismas páginas, en un móvil real y con caché fría.
Preguntas frecuentes
¿Qué ralentiza realmente un sitio web?
Normalmente son cuatro capas: imágenes más pesadas de lo que el diseño necesita, tipografías web que retrasan el texto, scripts de terceros que ocupan el hilo principal y estilos o scripts síncronos que bloquean el renderizado. El servidor y el protocolo son una segunda capa.
¿Cuánto cuesta una corrección puntual de velocidad?
El Site Fix Pack cuesta $70: hasta 5 correcciones acordadas, revisión en móvil y escritorio y una lista de antes/después en la entrega. Se entrega en 1-2 días laborables e incluye 1 ronda de revisiones. Páginas nuevas, rediseño y migraciones no forman parte de este paquete.
¿Y si el sitio es lento por cómo está construido?
Entonces la respuesta es rehacerlo. Sitio para lanzamiento cuesta $380: maquetación adaptable, conexión de un CMS básico o de los datos y configuración del despliegue. Se entrega en 3-5 días laborables con 2 rondas de revisiones antes del lanzamiento. El contenido y las traducciones los aporta el cliente.
¿Hace falta soporte una vez hechas las correcciones?
El Soporte técnico continuo cuesta $290/mes: actualizaciones prioritarias, un ritmo semanal de publicaciones y mantenimiento técnico. Funciona por ciclo mensual, el volumen se acuerda al principio de cada ciclo y se detiene avisando con 30 días. Una construcción nueva o un rediseño se presupuestan aparte.
¿Y si necesitamos funcionalidad nueva en lugar de una corrección?
Desarrollo de producto cuesta $880: entrega de funcionalidades, lógica de estado y de rutas, pruebas y refuerzo. Se entrega en 2-3 semanas con 2 rondas de revisiones por funcionalidad entregada. Las aplicaciones móviles nativas y las licencias de pago no están incluidas.