La web del camping donde trabaja Rocío Peinado Gálvez, en Cabo de Gata, contesta en 120 milisegundos y tarda 4,8 segundos en enseñar la primera foto. El servidor está bien. Lo que tarda ocurre entero después de que el servidor haya terminado.
Entre esas dos cifras hay cuatro etapas que ningún módulo mide, un fichero de 3,4 MB y un aviso de cookies que en España no es opcional. Ese hueco es este tema.
El umbral que Google llama bueno para esa segunda cifra está en 2,5 segundos, así que el camping va al doble con un servidor que no tiene ninguna culpa.
Seis etapas, y el servidor es dueño solo de la tercera
Pinchar un enlace no dispara una petición, dispara una secuencia. El nombre del sitio se convierte en un número, se abre y se cifra la conexión, el servidor contesta, el navegador lee lo que ha llegado, espera a lo que bloquea, y pinta.
La cuarta etapa es la que casi nadie tiene bien colocada: lo que llega del servidor no es la página, es una lista. El navegador hace una petición para el HTML y otra por cada fichero que el HTML nombra, y en la portada del camping ese HTML nombra 41 ficheros. La primera respuesta pesa 14 kB y llega enseguida; lo que viene detrás son cuarenta y una peticiones más, cada una con su propio viaje.
El TTFB mide el servidor y el LCP mide todo lo que viene después, y confundir esas dos siglas es lo que lleva a cambiar de hosting para arreglar una foto. En el camping el TTFB son 120 milisegundos y el LCP son 4,8 segundos, y el hosting nuevo movería la primera cifra.
Lo que detiene el pintado está en el head
El navegador puede pintar en cuanto tiene marcado y estilos, y por eso una hoja de estilos en el head detiene el pintado hasta que llega. No es un defecto: si pintara antes, la página aparecería sin formato y saltaría al recibirlo. El precio es que la pantalla se queda en blanco mientras tanto.
El camping tiene dos hojas en el head, una del tema y otra de una tipografía, y entre las dos son 640 milisegundos en los que no hay nada que ver. Los scripts hacen lo mismo salvo que se les diga otra cosa, y la palabra que se les dice es defer: defer descarga el script durante el análisis del HTML y lo ejecuta al final, con lo cual deja de estar en medio.
La foto de cabecera es el otro medio segundo largo. Pesa 3,4 MB porque salió de la cámara y entró en el gestor sin pasar por ningún sitio, y es justo el elemento que el LCP está midiendo. Servida al tamaño en que se ve y en un formato moderno, la misma foto baja de un megabyte y el LCP del camping se queda en 1,9 segundos, por debajo del umbral, sin tocar el servidor.
El aviso de cookies es una etapa más, y aquí la pone la AEPD
Toda esa secuencia tiene en España un paso que no sale en ningún diagrama en inglés. Ninguna etiqueta de terceros se carga antes del consentimiento: ni la medición, ni el mapa incrustado, ni el vídeo de la playa que el camping tiene en la portada, porque todos ellos dejan datos en el navegador de quien entra.
La guía de cookies de la AEPD pide además que rechazar cueste lo mismo que aceptar, en la misma capa del aviso y con la misma cantidad de clics. Un botón grande de aceptar y un enlace pequeño de configurar no cumple, y esa es la forma con la que llegan casi todas las plantillas.
Lo que eso significa para quien programa es concreto: la parte de la página que depende de terceros no se puede medir junto con el resto, porque hasta que alguien decide no existe. Y el propio aviso suele ser un script en el head, con lo cual entra en el párrafo anterior y bloquea el pintado de todo lo demás.
El 301 se queda guardado y el 302 no
El camping cambió las direcciones de las fichas de bungalós y Rocío puso una redirección para no perder los enlaces antiguos. Un 301 se queda guardado en el navegador y un 302 no, y esa diferencia es la que decide si un error se puede deshacer.
Quien haya visitado una dirección que devolvió un 301 no vuelve a pedirla: su navegador va directo al destino nuevo durante meses, sin preguntar. Si el destino estaba mal escrito, ese visitante se queda atrapado y no hay nada en el servidor que lo saque de ahí. Con un 302, la próxima visita vuelve a preguntar y el arreglo llega solo.
La regla de trabajo que sale de esto cabe en una línea: mientras se prueba, 302; cuando la dirección nueva ya es la definitiva, 301, que es además la que traspasa la reputación de la antigua.
La estructura
Lo que tiene que aguantar para que la capa de encima signifique algo
Se lee de arriba abajo. Cada capa se apoya en la de debajo, y una avería cae hacia arriba y sale por todas las demás.
- El framework de componentesDonde empieza casi todo el mundo, y la capa que menos años dura
- Los estilosColocación y aspecto, y el apartado más largo del tema
- El marcadoEstructura, significado, y si un lector de pantalla puede leer algo de esto
- El contrato por el cablePeticiones, códigos de estado y caché, que es lo que el temario deja para el final
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 hacer mal, porque todo lo de encima da por hecho que alguien las hizo.
Dónde se para quien sale del ciclo
El temario reparte esto en módulos y examina cada uno por separado: marcado, estilos, cliente, servidor. Sale gente que sabe escribir los cuatro y no ha visto nunca cargarse una página entera, porque ninguna prueba pone delante una cascada de peticiones.
El orden del temario deja para el final la capa sobre la que se apoyan las otras tres. Las peticiones, los códigos de estado y la caché no son un módulo avanzado: son el suelo, y las tres capas de encima dan por hecho que alguien lo entiende. Un componente que pide dos veces lo mismo, una hoja de estilos que llega la última y un 301 mal puesto son el mismo desconocimiento con tres disfraces.
La señal de haber salido de ahí es que la primera reacción ante una página lenta deja de ser una opinión sobre el framework y pasa a ser abrir la pestaña de red y ordenar por tiempo.
Qué abrir en 2026 para verlo
El panel de red del navegador es la herramienta principal y lleva instalada desde siempre en el ordenador donde estás leyendo esto. Es gratis, no pide cuenta, y sustituye a adivinar qué fichero iba lento y borrar cosas hasta que la página mejoraba. Enseña las 41 peticiones del camping en una cascada, con su tamaño y su momento, y la que bloquea se reconoce porque las demás empiezan cuando ella acaba.
Lighthouse está dentro de las mismas herramientas de desarrollo de Chrome, también es gratis, y sustituyó a discutir la velocidad como una impresión en vez de como una medida. Da el LCP y los otros dos indicadores con un número y una lista de causas ordenada por lo que costaría arreglarla.
El fallo típico con los dos es medir en el portátil de quien programa, con la caché caliente y con fibra. La cifra que importa es la de un móvil por datos a la entrada de un camping, y las dos herramientas saben simularla.
Por dónde entrar, y en qué orden
Lo primero que conviene abrir es lo que el temario dejó para el final, y aquí eso es el rendimiento web, porque es el único apartado que obliga a mirar la secuencia entera de una vez. Con esa secuencia delante, el HTML deja de ser una lista de etiquetas y pasa a ser lo que decide cuántas peticiones más va a haber.
Después vienen las dos mitades grandes. CSS es la más larga del tema y la que gobierna el bloqueo del que habla la tercera sección; el backend es donde vive esa tercera etapa, la única de las seis que un servidor mejor arregla.
Las APIs son el contrato entre esas dos mitades y se entienden mucho mejor después de haberlas visto pasar por la cascada. La seguridad web llega detrás, y no por importar menos: los ataques que recibe el camping se explican en los mismos códigos de estado y las mismas cabeceras que este tema acaba de usar.
La pregunta que deja abierta la portada del camping es qué pasa cuando el visitante no llega por un navegador sino por una aplicación que se instala, porque entonces las seis etapas siguen ahí y encima hay una tienda y un aparato con la batería contada. Eso es el desarrollo móvil, y el suelo compartido con este tema, el de las peticiones y los formatos, sigue siendo el mismo que en los fundamentos de programación y en los lenguajes de programación.