Como a web funciona

docs.scrimba.com

Toda página que você abre segue a mesma jornada curta. Você pede algo pelo seu endereço, uma máquina em algum lugar envia de volta um documento de texto, e seu navegador transforma esse texto na página que você vê. HTML é a linguagem em que esse texto é escrito, então entender o trajeto que ele faz é o pano de fundo para tudo mais neste manual.

Cliente e servidor

A web é uma conversa entre dois lados. Seu navegador é o cliente: o programa que pede páginas. A máquina que guarda um website e o entrega é o servidor. Você pede, ele responde.

Pense em fazer um pedido em um restaurante. Você é o cliente, a cozinha fica fora da vista, e um garçom leva seu pedido para frente e para trás. Você não entra na cozinha e cozinha. Você pede um prato, e a cozinha o prepara e o envia. Seu navegador é o cliente, o servidor é a cozinha, e a web é o garçom correndo entre eles.

Cada carregamento de página é um cliente conversando com um servidor. O cliente é o programa que faz a solicitação, quase sempre um navegador, mas também pode ser um aplicativo móvel ou uma ferramenta de linha de comando. O servidor é um programa rodando em uma máquina em algum lugar, esperando solicitações e enviando respostas.

O relacionamento é unidirecional no início: o cliente sempre fala primeiro. Um servidor não empurra uma página para você do nada. Ele fica sentado e espera até que um cliente peça algo, depois ele responde. Um servidor atende milhares de clientes ao mesmo tempo, o que é por isso que um único website pode servir muitos visitantes do mesmo endereço.

Cliente e servidor são papéis, não máquinas fixas. Um cliente é o que inicia uma solicitação; um servidor é o que escuta solicitações e retorna respostas. O mesmo computador físico pode ser um servidor para uma conexão e um cliente para outra, por exemplo um servidor web que ele próprio chama um banco de dados.

O modelo é orientado por solicitações e sem estado em seu núcleo. Sem estado significa que o servidor trata cada solicitação como completa por si própria: nada sobre a solicitação anterior é lembrado por padrão. É por isso que fazer login tem que ser reestabelecido em solicitações posteriores, geralmente com um cookie ou token que o cliente envia junto cada vez, porque a conexão em si não tem memória. Manter o protocolo sem estado é o que permite que um servidor escale para tráfego enorme, já que não mantém uma thread aberta de contexto para cada visitante entre solicitações.

JunoCliente e servidor Dois lados, uma conversa: seu navegador é o cliente que pede, o servidor é a máquina que responde. Como um cliente e uma cozinha com um garçom no meio, você nunca entra na cozinha, você faz o pedido e a comida sai. Guarde essa imagem em mente, tudo mais nesta página é uma versão dela.

JunoCliente e servidor Cliente pede, servidor responde, e o cliente sempre fala primeiro. Um servidor lida com muitos clientes ao mesmo tempo, o que é como um único endereço serve uma multidão de visitantes. Quando algo carrega, você está observando uma rodada daquele ir e vir.

JunoCliente e servidor Cliente e servidor são papéis, não caixas, e a mesma máquina pode desempenhar ambos. A web é sem estado por padrão, então o servidor não lembra de nada entre solicitações a menos que o cliente reenvia prova cada vez, o que é o que um cookie ou token está fazendo. Esse caráter sem estado não é uma limitação a contornar, é o que permite que um servidor aguente tráfego real.

URLs e domínios

O endereço que você digita é uma URL: um Localizador Uniforme de Recurso. É o endereço completo de uma coisa na web, a forma que um endereço postal aponta para uma casa.

Olhe para https://scrimba.com/learn. A parte https é como o navegador deve falar com o servidor. A parte scrimba.com é o domínio, o nome do website, como a rua e a cidade. A parte /learn é o caminho para uma página específica, como o número da casa. Juntos eles apontam para exatamente uma página, e digitá-los diz ao navegador para onde ir.

Uma URL é feita de partes, e nomeá-las torna tudo mais fácil de ler. Pegue https://scrimba.com/learn/html:

• https é o esquema: o protocolo que o navegador usa para buscar a página.
• scrimba.com é o domínio: o nome legível do site.
• /learn/html é o caminho: qual página nesse site.

O domínio é um substituto amigável para um número. Todo servidor é alcançável em um endereço IP, uma sequência como 192.0.2.10, e o nome do domínio é o que o salva de memorizar. Quando você digita um domínio, o navegador procura seu endereço IP através do DNS, o Sistema de Nomes de Domínio, que funciona como uma lista telefônica transformando nomes em números.

Uma URL codifica tudo o que o navegador precisa para localizar um recurso, e cada segmento tem um trabalho. Em https://shop.example.com:443/products?id=42#reviews: o esquema é https, shop é um subdomínio, example.com é o domínio registrado, 443 é a porta, /products é o caminho, ?id=42 é a string de consulta, e #reviews é o fragmento.

A porta é a porta numerada no servidor (443 é o padrão para HTTPS, então geralmente é omitida). A string de consulta passa parâmetros para o servidor, que pode mudar o que ele retorna. O fragmento após # é tratado apenas pelo navegador e nunca é enviado ao servidor; ele aponta para um local dentro da página. Resolver o domínio em um endereço IP passa por DNS (o Sistema de Nomes de Domínio, o diretório da web de nomes em números), e essa busca em si é uma rodada de rede, então uma resolução DNS fria é latência que o usuário paga antes de um único byte da página chegar. Conhecer a anatomia é prático: ele diz o que o servidor pode ver (caminho e consulta), o que ele não pode (o fragmento), e onde uma primeira carga lenta pode se esconder.

JunoURLs e domínios Uma URL é o endereço completo de uma página. O https diz como falar com o servidor, o domínio como scrimba.com é o nome do site, e o caminho como /learn aponta para uma página nele. Leia da esquerda para a direita e ela diz exatamente para onde o navegador está indo.

JunoURLs e domínios Uma URL se divide em esquema, domínio e caminho, e uma vez que você vê essas partes você pode ler qualquer endereço à primeira vista. O domínio é um nome amigável para um número: DNS é a lista telefônica que transforma scrimba.com em um endereço IP que o navegador pode realmente alcançar. Essa busca acontece silenciosamente antes da página carregar.

JunoURLs e domínios Cada parte de uma URL merece seu lugar: esquema, subdomínio, domínio, porta, caminho, consulta, fragmento. O servidor vê o caminho e a consulta mas nunca o fragmento, já que a parte após # fica no navegador. E a resolução DNS é uma rodada real, então uma busca fria é latência que o usuário paga antes do primeiro byte, o que vale a pena lembrar quando uma primeira carga se sente lenta.

O ciclo de solicitação e resposta

Quando você pressiona enter, seu navegador envia uma solicitação ao servidor: uma mensagem curta que diz "por favor envie para mim essa página". O servidor envia de volta uma resposta: a página em si. Esse ir e vir é uma viagem completa, e é o que acontece toda vez que você abre uma página ou clica em um link.

Imagine pedir a um bibliotecário por um livro. Você dá o título (sua solicitação), o bibliotecário o encontra e o entrega (a resposta), e agora você o tem nas mãos. Se o livro não existe, o bibliotecário diz isso para você, o que também é uma resposta. A web funciona da mesma forma, muito mais rápido e muitas vezes por segundo.

Um carregamento de página é uma solicitação e uma resposta. O navegador envia uma solicitação nomeando a página que quer e como quer; o servidor envia de volta uma resposta contendo a página, mais um código de status que diz como a solicitação correu.

Você verá três códigos de status constantemente, então aprenda esses primeiro:

• 200 OK: funcionou, aqui está o que você pediu.
• 404 Não Encontrado: o servidor está bem, mas não há nada nesse endereço.
• 301 Movido Permanentemente: essa página agora vive em outro lugar, e o navegador deve seguir para o novo endereço.

O que o servidor envia de volta para uma página normal não é uma imagem da página. É um documento de texto simples escrito em HTML, as mesmas tags que você escreve na mão. O navegador recebe esse texto e constrói a página visível a partir dele.

O ciclo de solicitação e resposta é definido por HTTP, o Protocolo de Transferência de Hipertexto: o conjunto acordado de regras para como um cliente e servidor fraseiam suas mensagens. Uma solicitação carrega um método (o verbo: GET para buscar, POST para enviar dados), um caminho, e cabeçalhos (pares de nome e valor de metadados, por exemplo que formatos o cliente aceita). A resposta carrega um código de status, seus próprios cabeçalhos, e geralmente um corpo, o conteúdo real.

Códigos de status vêm em intervalos, e o intervalo diz para quem olhar. 2xx é sucesso (200 OK). 3xx é redirecionamento (301 Movido Permanentemente diz ao navegador e aos mecanismos de busca que o recurso tem um novo endereço canônico, então vale a pena acertar para SEO). 4xx é um erro do cliente, significando que a solicitação estava errada (404 Não Encontrado, 403 Proibido). 5xx é um erro do servidor, significando que a solicitação estava bem mas o servidor falhou (500 Erro Interno do Servidor). A distinção é prática: um 4xx aponta você para a solicitação, um 5xx aponta você para o servidor. O corpo da resposta para um documento é texto HTML, e o cabeçalho Content-Type é o que diz ao navegador para tratá-lo como HTML em vez de texto simples ou uma imagem. Uma mais linha que vale a pena saber: HTTP envia tudo legível pela rede, enquanto HTTPS envolve o mesmo protocolo em criptografia para que ninguém no meio possa ler ou mexer com ele, o que é por isso que cada site real usa HTTPS hoje.

JunoO ciclo de solicitação e resposta Toda página é um ir e vir: seu navegador envia uma solicitação que diz por favor envie isso para mim, e o servidor envia uma resposta com a página. Como pedir a um bibliotecário por um livro e ganhá-lo, ou ser dito que não está aqui. Essa rodada de ida e volta acontece toda vez que você abre uma página, silenciosamente e rápido.

JunoO ciclo de solicitação e resposta Uma solicitação para fora, uma resposta de volta, com um código de status anexado. Aprenda 200 (funcionou), 404 (nada nesse endereço), e 301 (movido, me siga) primeiro, eles cobrem a maioria do que você verá. E lembre que o que realmente volta para uma página é texto HTML simples, não uma imagem, que o navegador então constrói na visão.

JunoO ciclo de solicitação e resposta HTTP é a gramática da viagem: uma solicitação tem um método, caminho e cabeçalhos, uma resposta tem um código de status, cabeçalhos e um corpo. Leia códigos de status por intervalo, um 4xx significa corrigir a solicitação, um 5xx significa que o servidor caiu, e essa divisão diz onde olhar. O corpo é texto HTML marcado por Content-Type, e HTTPS é HTTP com criptografia envolvida, o que é por isso que todo site real usa.

O que o navegador faz com o HTML que recebe

A resposta é o texto HTML de uma página. Seu navegador lê esse texto de cima para baixo e o desenha na tela: vê uma tag de título e mostra texto grande e ousado, vê uma tag de parágrafo e mostra uma linha de texto do corpo, vê uma tag de imagem e busca a imagem.

Você pode pensar nisso como ler uma receita e cozinhá-la. O texto não é a refeição, é a descrição da refeição, e o navegador é o cozinheiro que transforma a descrição em algo que você pode realmente ver e usar. O mesmo HTML sempre produz a mesma página, porque o navegador segue as mesmas instruções toda vez.

O navegador não mostra o texto HTML, ele constrói uma página a partir dele. Conforme lê o documento de cima para baixo, ele transforma as tags em DOM, o Modelo de Objeto de Documento: uma árvore viva dos elementos da página mantida na memória. O DOM é o que realmente é exibido e o que CSS e JavaScript depois leem e modificam.

A ordem importa aqui. O navegador lê o documento na ordem em que você escreveu, então uma <script> ou um stylesheet próximo ao topo é tratado antes do conteúdo abaixo dele. Esta é a razão prática de páginas colocarem informações sobre a página na <head> e seu conteúdo visível no <body>, e por que onde você coloca uma tag afeta quando seu efeito acontece. Você não está apenas listando elementos, você está entregando ao navegador uma ordem de leitura.

Transformar HTML em pixels é um pipeline, e conhecer sua forma diz por que algumas páginas pintam mais lentamente que outras. O navegador analisa o texto HTML (lê e constrói estrutura) no DOM (o Modelo de Objeto de Documento: a árvore em memória de cada elemento). Ele analisa CSS em uma árvore paralela, combina os dois, calcula a geometria (layout: onde cada caixa fica), e finalmente pinta pixels na tela.

Porque o analisador lê de cima para baixo, a colocação muda o tempo. Um recurso é de bloqueio de renderização quando o navegador não pintará conteúdo até terminar com esse recurso. Um stylesheet na <head> é de bloqueio de renderização por design, então a página não pisca sem estilo, mas um lento prende todo o primeiro quadro. Uma <script> clássica na <head> é pior: o analisador para, baixa e executa o script, depois retoma, então um script alto no documento atrasa cada elemento abaixo dele (os atributos defer e async existem para quebrar esse bloqueio). É por isso que a ordem do documento e a colocação na <head> decidem o que pinta primeiro: tudo acima de um recurso de bloqueio espera por ele.

Isso se conecta a latência, o tempo que um byte leva para viajar ao usuário, que nenhuma quantidade de velocidade local remove. Toda solicitação tem um custo de rodada de ida e volta, então menos solicitações e bytes menores e mais cedo significam que a página começa a pintar mais cedo. O que você controla no HTML é a ordem: coloque o que o usuário precisa ver primeiro bem no topo do documento, mantenha os recursos de bloqueio fora do seu caminho, e o primeiro quadro significativo chega mais cedo. Menos e bytes mais cedo é todo o jogo de desempenho nesta camada.

JunoO que o navegador faz com o HTML que recebe O HTML que volta é uma descrição da página, e o navegador é o cozinheiro que transforma em realidade. Ele lê de cima para baixo: tag de título, texto grande e ousado, tag de parágrafo, texto do corpo, tag de imagem, busque a imagem. Mesmo HTML dentro, mesma página para fora, toda vez.

JunoO que o navegador faz com o HTML que recebe O navegador lê seu HTML de cima para baixo e constrói o DOM, uma árvore viva de elementos que é o que é realmente mostrado. Porque ele lê em ordem, onde você coloca uma tag decide quando ela toma efeito, que é a razão real para a divisão entre head e body. Você está entregando ao navegador uma ordem de leitura, não apenas uma pilha de elementos.

JunoO que o navegador faz com o HTML que recebe Analise para DOM, combine com CSS, organize, pinte: esse pipeline é por que a colocação muda o tempo. Qualquer coisa acima de um recurso de bloqueio de renderização espera por ele, então um stylesheet lento ou uma <script> simples na head prende o primeiro quadro, o que defer e async são para. Adicione latência que você não pode remover, e o movimento é sempre o mesmo, menos e bytes mais cedo, com o que importa mais bem no topo do documento.