Cómo funciona la web

docs.scrimba.com

Cada página que abres sigue el mismo viaje corto. Pides algo por su dirección, una máquina en algún lugar envía de vuelta un documento de texto, y tu navegador convierte ese texto en la página que ves. HTML es el lenguaje en el que ese texto está escrito, así que entender el viaje que hace es el telón de fondo para todo lo demás en este manual.

Cliente y servidor

La web es una conversación entre dos lados. Tu navegador es el cliente: el programa que solicita páginas. La máquina que contiene un sitio web y lo entrega es el servidor. Tú pides, él responde.

Piensa en hacer un pedido en un restaurante. Tú eres el cliente, la cocina está fuera de vista, y un mesero lleva tu pedido de un lado a otro. No caminas hacia la cocina y cocinas. Pides un plato, y la cocina lo prepara y lo envía. Tu navegador es el cliente, el servidor es la cocina, y la web es el mesero corriendo entre ellos.

Cada carga de página es un cliente hablando con un servidor. El cliente es el programa que realiza la solicitud, casi siempre un navegador, pero también puede ser una aplicación móvil o una herramienta de línea de comandos. El servidor es un programa que se ejecuta en una máquina en algún lugar, esperando solicitudes y enviando respuestas.

La relación es unidireccional al principio: el cliente siempre habla primero. Un servidor no te empuja una página de la nada. Se sienta y espera hasta que un cliente pide algo, luego responde. Un servidor responde a miles de clientes a la vez, por eso un solo sitio web puede servir a muchos visitantes desde la misma dirección.

Cliente y servidor son roles, no máquinas fijas. Un cliente es lo que inicia una solicitud; un servidor es lo que escucha solicitudes y devuelve respuestas. La misma computadora física puede ser un servidor para una conexión y un cliente para otra, por ejemplo un servidor web que a su vez llama a una base de datos.

El modelo es impulsado por solicitudes y sin estado en su esencia. Sin estado significa que el servidor trata cada solicitud como completa en sí misma: nada sobre la solicitud anterior se recuerda por defecto. Por eso iniciar sesión tiene que restablecerse en solicitudes posteriores, generalmente con una cookie o token que el cliente envía cada vez, porque la conexión en sí no lleva memoria. Mantener el protocolo sin estado es lo que permite que un servidor escale a un tráfico enorme, ya que no mantiene un hilo abierto de contexto para cada visitante entre solicitudes.

JunoCliente y servidor Dos lados, una conversación: tu navegador es el cliente que pide, el servidor es la máquina que responde. Como un cliente y una cocina con un mesero en medio, nunca entras en la cocina, haces el pedido y la comida sale. Mantén esa imagen, todo lo demás en esta página es una versión de eso.

JunoCliente y servidor El cliente pide, el servidor responde, y el cliente siempre habla primero. Un servidor maneja muchos clientes a la vez, así es como una sola dirección sirve a toda una multitud de visitantes. Cuando algo carga, estás viendo una ronda de ese ir y venir.

JunoCliente y servidor Cliente y servidor son roles, no cajas, y la misma máquina puede jugar ambos. La web es sin estado por defecto, así que el servidor no recuerda nada entre solicitudes a menos que el cliente reenvíe prueba cada vez, que es lo que hace una cookie o token. Ese carácter sin estado no es una limitación que superar, es lo que permite que un servidor aguante tráfico real.

URLs y dominios

La dirección que escribes es una URL: un Localizador Uniforme de Recursos. Es la dirección completa de una cosa en la web, la forma en que una dirección postal apunta a una casa.

Mira https://scrimba.com/learn. La parte https es cómo el navegador debe hablar con el servidor. La parte scrimba.com es el dominio, el nombre del sitio web, como la calle y la ciudad. La parte /learn es la ruta a una página particular, como el número de casa. Juntos apuntan exactamente a una página, y escribirlos le dice al navegador a dónde ir.

Una URL está hecha de partes, y nombrarlas hace que todo sea más fácil de leer. Toma https://scrimba.com/learn/html:

• https es el esquema: el protocolo que el navegador usa para obtener la página.
• scrimba.com es el dominio: el nombre legible del sitio.
• /learn/html es la ruta: qué página en ese sitio.

El dominio es un sustituto amigable para un número. Cada servidor es accesible en una dirección IP, una cadena como 192.0.2.10, y el nombre de dominio es lo que te ahorra memorizarla. Cuando escribes un dominio, el navegador busca su dirección IP a través del DNS, el Sistema de Nombres de Dominio, que funciona como una guía telefónica que convierte nombres en números.

Una URL codifica todo lo que el navegador necesita para localizar un recurso, y cada segmento tiene un trabajo. En https://tienda.ejemplo.com:443/productos?id=42#resenas: el esquema es https, tienda es un subdominio, ejemplo.com es el dominio registrado, 443 es el puerto, /productos es la ruta, ?id=42 es la cadena de consulta, y #resenas es el fragmento.

El puerto es la puerta numerada en el servidor (443 es el predeterminado para HTTPS, por lo que generalmente se omite). La cadena de consulta pasa parámetros al servidor, que pueden cambiar lo que devuelve. El fragmento después de # es manejado solo por el navegador y nunca se envía al servidor; señala una ubicación dentro de la página. La resolución del dominio a una dirección IP va a través de DNS (el Sistema de Nombres de Dominio, el directorio de la web de nombres a números), y esa búsqueda en sí es una ronda de viaje de red, así que una resolución DNS en frío es latencia que el usuario paga antes de que llegue un solo byte de la página. Conocer la anatomía es práctico: te dice qué puede ver el servidor (ruta y consulta), qué no puede (el fragmento), y dónde puede ocultarse una carga lenta al inicio.

JunoURLs y dominios Una URL es la dirección completa de una página. El https dice cómo hablar con el servidor, el dominio como scrimba.com es el nombre del sitio, y la ruta como /learn apunta a una página en él. Léelo de izquierda a derecha y te dice exactamente a dónde va el navegador.

JunoURLs y dominios Una URL se divide en esquema, dominio y ruta, y una vez que ves esas partes puedes leer cualquier dirección de un vistazo. El dominio es un nombre amigable para un número: DNS es la guía telefónica que convierte scrimba.com en una dirección IP a la que el navegador puede llegar. Esa búsqueda ocurre silenciosamente antes de que la página cargue.

JunoURLs y dominios Cada parte de una URL se gana su lugar: esquema, subdominio, dominio, puerto, ruta, consulta, fragmento. El servidor ve la ruta y la consulta pero nunca el fragmento, ya que la parte después de # permanece en el navegador. Y la resolución de DNS es un viaje real, así que una búsqueda en frío es latencia que el usuario paga antes del primer byte, lo que vale la pena recordar cuando una carga inicial se siente lenta.

El ciclo de solicitud y respuesta

Cuando presionas enter, tu navegador envía una solicitud al servidor: un mensaje corto que dice "por favor envíame esta página". El servidor envía de vuelta una respuesta: la página en sí. Ese ir y venir es un viaje completo, y es lo que sucede cada vez que abres una página o haces clic en un enlace.

Imagina pedirle a un bibliotecario un libro. Das el título (tu solicitud), el bibliotecario lo encuentra y te lo entrega (la respuesta), y ahora lo tienes en tus manos. Si el libro no existe, el bibliotecario te lo dice en su lugar, que es una respuesta también. La web funciona de la misma manera, mucho más rápido y muchas veces por segundo.

Una carga de página es una solicitud y una respuesta. El navegador envía una solicitud nombrando la página que quiere y cómo la quiere; el servidor envía una respuesta que contiene la página, más un código de estado que dice cómo fue la solicitud.

Verás tres códigos de estado constantemente, así que aprende estos primero:

• 200 OK: funcionó, aquí está lo que pediste.
• 404 Not Found: el servidor está bien, pero no hay nada en esa dirección.
• 301 Moved Permanently: esta página ahora vive en otro lugar, y el navegador debe ir a la nueva dirección.

Lo que el servidor envía de vuelta para una página normal no es una imagen de la página. Es un documento de texto plano escrito en HTML, las mismas etiquetas que escribes a mano. El navegador recibe ese texto y construye la página visible a partir de él.

El ciclo de solicitud y respuesta es definido por HTTP, el Protocolo de Transferencia de Hipertexto: el conjunto acordado de reglas para cómo un cliente y servidor redactan sus mensajes. Una solicitud lleva un método (el verbo: GET para obtener, POST para enviar datos), una ruta, y encabezados (pares de nombre y valor de metadatos, por ejemplo qué formatos acepta el cliente). La respuesta lleva un código de estado, sus propios encabezados, y generalmente un cuerpo, el contenido real.

Los códigos de estado vienen en rangos, y el rango te dice a quién mirar. 2xx es éxito (200 OK). 3xx es redirección (301 Moved Permanently le dice al navegador y a los motores de búsqueda que el recurso tiene una nueva dirección canónica, así que vale la pena hacerlo bien para SEO). 4xx es un error del cliente, lo que significa que la solicitud fue incorrecta (404 Not Found, 403 Forbidden). 5xx es un error del servidor, lo que significa que la solicitud fue correcta pero el servidor falló (500 Internal Server Error). La distinción es práctica: un 4xx te apunta a la solicitud, un 5xx te apunta al servidor. El cuerpo de la respuesta para un documento es texto HTML, y el encabezado Content-Type es lo que le dice al navegador que lo trate como HTML en lugar de texto plano o una imagen. Una línea más que vale la pena conocer: HTTP envía todo legible por el cable, mientras que HTTPS envuelve el mismo protocolo en encriptación para que nadie en el medio pueda leerlo o alterarlo, por eso cada sitio real usa HTTPS hoy.

JunoEl ciclo de solicitud y respuesta Cada página es un ir y venir: tu navegador envía una solicitud que dice por favor envíame esto, y el servidor envía una respuesta con la página. Como pedirle un libro a un bibliotecario y recibirlo, o que te diga que no está aquí. Ese viaje de ida y vuelta ocurre cada vez que abres una página, silenciosamente y rápido.

JunoEl ciclo de solicitud y respuesta Una solicitud, una respuesta, con un código de estado adjunto. Aprende primero 200 (funcionó), 404 (nada en esa dirección), y 301 (se movió, sígueme), cubren la mayoría de lo que verás. Y recuerda que lo que realmente viene de vuelta para una página es texto HTML plano, no una imagen, que el navegador luego construye en la vista.

JunoEl ciclo de solicitud y respuesta HTTP es la gramática del viaje: una solicitud tiene un método, ruta y encabezados, una respuesta tiene un código de estado, encabezados y un cuerpo. Lee los códigos de estado por rango, un 4xx significa arregla la solicitud, un 5xx significa que el servidor se cayó, y esa división te dice dónde mirar. El cuerpo es texto HTML etiquetado por Content-Type, y HTTPS es HTTP con encriptación envuelta alrededor, por eso cada sitio real lo usa.

Lo que el navegador hace con el HTML que recibe

La respuesta es una página de texto HTML. Tu navegador lee ese texto de arriba a abajo y lo dibuja en la pantalla: ve una etiqueta de encabezado y muestra texto grande en negrita, ve una etiqueta de párrafo y muestra una línea de texto del cuerpo, ve una etiqueta de imagen y obtiene la imagen.

Puedes pensarlo como leer una receta y cocinarla. El texto no es la comida, es la descripción de la comida, y el navegador es el cocinero que convierte la descripción en algo que realmente puedes ver y usar. El mismo HTML siempre produce la misma página, porque el navegador sigue las mismas instrucciones cada vez.

El navegador no muestra el texto HTML, construye una página a partir de él. Mientras lee el documento de arriba a abajo, convierte las etiquetas en el DOM, el Modelo de Objeto del Documento: un árbol vivo de los elementos de la página mantenido en la memoria. El DOM es lo que realmente se muestra y lo que CSS y JavaScript después leen y cambian.

El orden importa aquí. El navegador lee el documento en el orden en que lo escribiste, así que una <script> o una hoja de estilo cerca de la parte superior se trata antes del contenido debajo de ella. Esta es la razón práctica por la que las páginas ponen información sobre la página en el <head> y su contenido visible en el <body>, y por qué dónde colocas una etiqueta afecta cuándo sucede su efecto. No estás solo listando elementos, estás dándole al navegador un orden de lectura.

Convertir HTML en píxeles es un pipeline, y conocer su forma te dice por qué algunas páginas se pintan más lentamente que otras. El navegador analiza el texto HTML (lo lee y construye estructura) en el DOM (el Modelo de Objeto del Documento: el árbol en memoria de cada elemento). Analiza CSS en un árbol paralelo, combina los dos, calcula la geometría (diseño: dónde se sienta cada caja), y finalmente pinta píxeles en la pantalla.

Porque el analizador lee de arriba a abajo, el cambio de colocación cambia el tiempo. Un recurso es bloqueante de renderización cuando el navegador no pintará contenido hasta que haya terminado con ese recurso. Una hoja de estilo en el <head> es bloqueante de renderización por diseño, así que la página no parpadea sin estilo, pero una lenta bloquea toda la primera pintura. Una <script> clásica en el <head> es peor: el analizador se detiene, descarga y ejecuta el script, luego reanuda, así que un script alto en el documento retrasa cada elemento debajo de él (los atributos defer y async existen para romper ese bloque). Por eso el orden del documento y la colocación en <head> deciden qué se pinta primero: todo por encima de un recurso bloqueante espera en él.

Eso se conecta con la latencia, el tiempo que tarda un byte en viajar al usuario, que ninguna cantidad de velocidad local elimina. Cada solicitud tiene un costo de viaje de ida y vuelta, así que menos solicitudes y bytes más pequeños y anteriores significan que la página comienza a pintarse más rápido. El lever que controlas en el HTML es el orden: pon lo que el usuario necesita ver primero alto en el documento, mantén los recursos bloqueantes fuera de su camino, y la primera pintura significativa llega antes. Menos y bytes anteriores es todo el juego de rendimiento en esta capa.

JunoLo que el navegador hace con el HTML que recibe El HTML que regresa es una descripción de la página, y el navegador es el cocinero que la convierte en la cosa real. Lee de arriba a abajo: etiqueta de encabezado, texto grande en negrita, etiqueta de párrafo, texto del cuerpo, etiqueta de imagen, obtén la imagen. Mismo HTML adentro, misma página afuera, cada vez.

JunoLo que el navegador hace con el HTML que recibe El navegador lee tu HTML de arriba a abajo y construye el DOM, un árbol vivo de elementos que es lo que realmente se muestra. Porque lee en orden, dónde pones una etiqueta decide cuándo tiene efecto, que es la razón real de la división head y body. Estás dándole al navegador un orden de lectura, no solo un montón de elementos.

JunoLo que el navegador hace con el HTML que recibe Analizar a DOM, combinar con CSS, diseñar, pintar: ese pipeline es por qué el cambio de colocación cambia el tiempo. Cualquier cosa por encima de un recurso bloqueante de renderización espera en él, así que una hoja de estilo lenta o una <script> simple en el head bloquea la primera pintura, que es lo que defer y async son. Agrega latencia que no puedes eliminar, y el movimiento es siempre el mismo, menos y bytes anteriores, con lo que importa más arriba en el documento.