Faragiri

Aprender Desarrollo webProgramación

Una página lenta casi nunca es un servidor lento. Qué pasa entre el toque y el texto, y por qué el sitio se siente rápido solo en la máquina de quien lo hizo.

5Secciones
7Minutos
2Profundidad

Un toque, una página

Seis etapas, y el servidor es dueño solamente de la tercera

Cada etapa tiene que terminar antes de que empiece la siguiente, y la que la gente optimiza casi nunca es la que va lenta.

  1. 01Encontrar la direcciónUn nombre se convierte en un número. Se guarda con ganas, y es invisible hasta que falla.
  2. 02Abrir y asegurar la conexiónDos viajes de ida y vuelta antes de pedir el primer byte de la página.
  3. 03El servidor contestaEl TTFB vive aquí y solamente aquí. Esta es la parte que arregla un servidor más rápido.
  4. 04Leer el marcadoNo es la página. Es una lista que nombra cada uno de los demás archivos que hacen falta.
  5. 05Esperar lo que bloqueaUna hoja de estilos en el head sostiene una pantalla en blanco hasta que aterriza.
  6. 06Pintar y después rellenarEl LCP se mide aquí, cuatro etapas después de que el servidor terminó.

Deja fuera el caché, que en una segunda visita borra etapas enteras y es la razón por la que un sitio le parece bien a quien lo hizo y lento a todos los demás.

La lista de precios de Nayibe Zapata, que vende uniformes escolares en Cali, pesa 4.2 MB y tarda siete segundos en aparecer en un teléfono. El servidor contesta en 90 milisegundos. Los seis segundos y pico restantes ocurren después de que la respuesta llegó, y los megabytes no los paga el servidor: los paga la clienta, con su paquete de datos prepago.

Nayibe no ve nada de eso. Arma el sitio en un portátil conectado al wifi del local, donde la página abre de inmediato porque el navegador ya tiene todo guardado y porque ahí los megabytes no se cuentan.

La web son dos máquinas y un contrato entre ellas. Casi toda pregunta archivada en este tema es en realidad la misma: de qué lado del contrato está el problema. Y la respuesta suele estar en un panel que la mayoría de quienes hacen sitios nunca ha abierto.

Lo que de verdad pasa entre el toque y el texto

Un teléfono pidió una página. Buscó la dirección, abrió una conexión, la aseguró, mandó una línea de petición y recibió de vuelta un archivo de marcado. Ese archivo no es la página. Es una lista de instrucciones que nombra todo lo demás que la página necesita, porque el navegador hace una petición por el HTML y una más por cada archivo que ese HTML nombra. La lista de Nayibe nombra 34: una hoja de estilos, dos tipografías, un script de estadísticas y 30 fotos de uniformes que salieron del teléfono sin que nadie las tocara.

Por eso el tiempo del servidor y el tiempo de la página son dos números distintos con dos responsables distintos. El TTFB mide al servidor y el LCP mide todo lo que pasa después. El TTFB de Nayibe son 90 milisegundos y está muy bien. Su LCP son 6.8 segundos, y ningún trabajo sobre el servidor lo va a mover, porque el servidor ya terminó.

El archivo que detiene el pintado, y los que cobran megabytes

De esas 34 peticiones, la mayoría puede llegar cuando quiera. Dos no. Una hoja de estilos en el head detiene el pintado hasta que llega: el navegador se niega a dibujar texto que quizá tenga que volver a dibujar con otra tipografía y otro tamaño, así que espera, y en una conexión lenta esa espera es una pantalla blanca. La hoja de Nayibe es un solo archivo de 180 kB con los estilos de todo el sitio, y la lista de precios usa como una décima parte.

La reparación no es un framework. Es poner las reglas que pintan la primera pantalla adentro del marcado y dejar que el resto llegue tarde, lo cual convierte seis segundos en blanco en texto a los 400 milisegundos y fotos que se van rellenando detrás. Ese trato y los que están a su lado son de lo que está hecho el rendimiento web.

Las 30 fotos son la otra mitad, y esa cuenta la edición en inglés no tiene motivo para hacer, porque su lectora está en wifi. Aquí no. Las fotos de Nayibe pesan 3.6 MB entre todas porque son el archivo que devuelve la cámara, de 4032 píxeles de ancho, mostradas en una columna de 320. Servidas al ancho en que se ven y en un formato moderno, las mismas 30 fotos pesan alrededor de 280 kB. Una clienta que revisa la lista tres veces en una semana gasta 12.6 MB en mirar precios; con las fotos servidas al tamaño correcto y con la respuesta guardada, las tres visitas cuestan cerca de 410 kB.

El otro medio kilo de esa reparación es una línea de marcado. loading="lazy" impide que el navegador baje una foto antes de que el lector se acerque a ella, y en una lista de 30 uniformes en la que casi nadie llega al final, eso solo ya deja fuera la mayoría de las descargas. Es una palabra en el atributo, no una biblioteca, y vive en HTML.

Redirecciones, y la que el navegador se acuerda

El sitio de Nayibe tenía un segundo problema debajo del primero. La dirección vieja de la lista seguía existiendo y mandaba a la nueva, así que cada teléfono que alguna vez fue enviado por ahí hacía dos viajes de ida y vuelta en lugar de uno. El código de estado decide cuánto cuesta eso. Un 301 es permanente y un 302 no, y el navegador se guarda el 301. Un 301 se paga una vez por navegador y después desaparece. Un 302 se paga en cada visita, para siempre, porque al navegador le dijeron que el arreglo era temporal y vuelve a preguntar con toda obediencia.

La dirección vieja devolvía un 302 que alguien puso en 2022 como prueba. Cambiar un número en una línea de configuración le quitó un viaje a cada visitante que regresa, y es la clase de reparación que resulta invisible en el código y evidente en los números.

El mismo instinto cubre las fotos. Un navegador se queda con un archivo que ya bajó si el servidor le dice por cuánto tiempo puede, y ese permiso es un encabezado de una línea. Las fotos de Nayibe no traían ninguno, así que la clienta que miraba precios el lunes y el jueves bajó los mismos uniformes dos veces. Por eso un sitio le parece rápido a quien lo hizo: su navegador ya tiene todo, y la medición que le corresponde leer es la primera visita y no la suya.

La estructura

Qué tiene que sostenerse para que la capa de arriba signifique algo

Se lee de la punta hacia abajo. Cada capa descansa en la de abajo, y una falla cae hacia arriba, sobre todas las demás.

  1. El framework de componentesDonde empieza casi todo el mundo, y la capa con la memoria más corta
  2. Los estilosAcomodo y apariencia, y la materia más grande del tema
  3. El marcadoEstructura, significado, y si un lector de pantalla puede leer algo de esto
  4. El contrato que viaja por el cablePeticiones, códigos de estado y caché, que las tres de arriba heredan sin enterarse

No dice cuánto código es cada capa. Las dos de abajo son las más cortas de escribir y las más caras de equivocar, porque todo lo de arriba da por hecho que quedaron bien.

El orden de aprenderlo, y lo que pasa al cuarto mes

El orden que sirve es el que usa el navegador, y es de los pocos lugares de programación donde la secuencia de la máquina y la del temario coinciden. Primero CSS no; primero el marcado, porque todo lo demás se cuelga de él y porque un documento bien estructurado ya es accesible, ya es indexable y ya se lee sin un solo estilo. Después CSS, que es la materia más grande del tema y la que más se salta quien entra directo por los componentes.

Tomado al revés la falla es específica y muy común: alguien aprende un framework de componentes primero, sabe armar una interfaz y no sabe decir qué es un elemento ni por qué la página no tiene encabezados. Está produciendo, y está construyendo algo que un lector de pantalla no puede leer, y ni el framework ni el tutorial se lo van a mencionar.

El atasco de este tema llega como a los cuatro meses y es el backend. Hasta ahí todo han sido archivos que un navegador abre. Entonces un formulario tiene que recordar algo, y de golpe aparecen un servidor, una base de datos, una sesión, un despliegue y una variable de entorno, y nada de eso es la materia que la persona creía estar estudiando. Backend es una disciplina distinta con el mismo título de trabajo, y tratarla como más de lo mismo es lo que hace que el cuarto mes se sienta un fracaso.

Qué abrir en 2026, y el ajuste que casi nadie toca

El panel de red de las herramientas del navegador es lo más útil de esta página. Lista las 34 peticiones en orden, con qué bloqueó a qué y cuántos kilobytes pesó cada una, y reemplazó la práctica de adivinar cuál archivo iba lento y borrar cosas hasta que la página mejorara. Es gratis y ya está instalado, sin cuenta y sin tarjeta.

Adentro del mismo panel hay un selector que dice red rápida, y ahí está el ajuste que casi nadie toca. Bajarlo a una conexión móvil lenta y marcar la casilla que vacía el caché es lo que le muestra a Nayibe la página que ve su clienta y no la que ve ella. Dos clics, ningún costo, y es la diferencia entre medir el sitio y medir el propio wifi.

Lighthouse, en ese mismo lugar, le pone nombre y meta a los números, y es la herramienta que convirtió la velocidad de una página de opinión en medición. Sus puntajes son un resumen y no un diagnóstico: le dice a Nayibe que su LCP son 6.8 segundos y no le dice que la causa son una hoja de estilos y 30 fotos de 4032 píxeles.

Lo que nada de esto cubre es qué ocurre cuando las dos máquinas no son un navegador y un servidor sino dos programas sin nadie esperando, que es otro contrato con otras reglas y es de lo que tratan las APIs. Y cuando la pantalla del otro lado deja de ser una pestaña y pasa a ser algo instalado, con batería y con permisos, la pregunta se muda entera a el desarrollo móvil.

Al lado de esto

Arriba de esto