- Um guia de aprendizado interativo criado para que engenheiros web e usuários em geral possam entender de forma intuitiva como um navegador funciona por dentro
- Visualiza passo a passo o processo, desde a digitação na barra de endereço até a criação da requisição HTTP, resolução de DNS, conexão TCP, parsing de HTML, construção do DOM e pipeline de renderização
- Cada etapa é composta por exemplos que podem ser inseridos ou manipulados diretamente, permitindo experimentar na prática os processos de comunicação em rede e renderização
- Mostra com clareza o papel do DOM e a diferença entre as etapas de Layout–Paint–Composite, permitindo ver visualmente os fatores que afetam o desempenho
- Um material para aprender de forma estruturada os conceitos centrais para desenvolvedores que querem estudar a arquitetura dos navegadores ou entender otimização de performance web
Visão geral
- Este guia foi criado para quem usa a web todos os dias, mas ainda não entende claramente como o navegador funciona
- Ele busca compensar as limitações de materiais existentes, que costumam ser técnicos demais ou superficiais demais
- Foi projetado para permitir o aprendizado intuitivo de detalhes técnicos por meio de pequenos exemplos interativos
- Detalhes como versões de HTTP, SSL/TLS e funcionamento interno do DNS foram omitidos, e o conteúdo foi organizado de forma concisa com foco nos conceitos centrais
- O projeto foi publicado como código aberto, e melhorias podem ser sugeridas pelo GitHub
Navegador e URL
- Toda string digitada pelo usuário na barra de endereço é convertida internamente para o formato de URL
- Após pressionar Enter, há uma interface prática que permite ver diretamente esse processo de conversão
Convertendo URL em requisição HTTP
Resolução do endereço do servidor (DNS)
- O navegador não consegue usar diretamente nomes de domínio como
example.com
- É necessário convertê-los em endereços IP por meio do sistema DNS para conseguir se comunicar com o servidor
- Ao digitar um domínio no campo de entrada, é possível ver o resultado da resolução DNS (endereço IP)
Estabelecimento da conexão TCP
- Depois de obter o IP via DNS, o navegador estabelece uma conexão confiável com o servidor usando o protocolo TCP
- A conexão é estabelecida por meio do processo de three-way handshake
- SYN: o cliente solicita a conexão
- SYN-ACK: o servidor responde e confirma
- ACK: o cliente faz a confirmação final
- O TCP mantém uma comunicação estável por meio de garantia de ordem dos dados e retransmissão
- Também é possível desconectar a rede ou manipular pacotes para experimentar a estabilidade da transmissão
Requisição e resposta HTTP
- Após a conexão TCP, o navegador envia a requisição HTTP, e o servidor retorna a resposta HTTP
- O trajeto da requisição e da resposta é mostrado visualmente, permitindo observar o fluxo dos pacotes
- Quando a resposta chega, o navegador separa cabeçalhos e corpo e começa a renderizar o HTML
Parsing de HTML e criação da árvore DOM
- O navegador envia os bytes do HTML para um parser, que constrói a árvore DOM
- Ao inserir um HTML de exemplo, é possível ver visualmente o processo em que tags como
<h1> e <p> são convertidas em nós do DOM
- O parsing ocorre de forma streaming, permitindo criar nós mesmo antes de o documento inteiro ter chegado
- Quando aparece uma tag
<script>, o parsing é pausado temporariamente para executar o script
- O DOM concluído é combinado com o CSS para formar a render tree
A importância do DOM
- O DOM (Document Object Model) é o modelo do documento na memória do navegador e é a estrutura central compartilhada pelo parser de HTML, pelo mecanismo de seletores CSS e pelo runtime de JavaScript
- Mudanças no DOM são refletidas imediatamente em layout, estilo e interação do usuário
- Ao modificar o código JavaScript, há uma função de visualização que mostra as mudanças no DOM em tempo real
Layout, Paint, Composite
- Quando DOM e CSS estão prontos, o navegador executa o pipeline de renderização
- Layout (Reflow): calcula o tamanho e a posição dos elementos
- Paint: preenche os pixels
- Composite: combina camadas na GPU
- Alterações de cor executam novamente apenas o Paint, mas alterações de tamanho executam novamente Layout e Paint
- É possível clicar para verificar se cada etapa é reexecutada
- O guia mostra visualmente que páginas com muitas operações de Layout renderizam mais lentamente
Resumo
- Um guia para aprender experimentando diretamente todo o processo, da digitação do endereço até a renderização
- Ao concluir todas as etapas, é possível formar um modelo mental claro de como o navegador funciona
- O projeto é open source, e melhorias podem ser sugeridas no GitHub por meio de issues ou Pull Requests
1 comentários
Comentários no Hacker News
Nem todos os navegadores tiveram DOM desde o início
No começo havia WorldWideWeb (Nexus, 1990), Erwise (1992), ViolaWWW (1992), Lynx (1992), NCSA Mosaic (1993), Netscape 1.0 (1994) e IE 1.0 (1995)
O Lynx ainda hoje continua intencionalmente como um navegador sem DOM
O AOL 1.0–2.0 usava um motor estático (AOLPress) sem objetos programáveis
A possibilidade de interagir com o DOM só surgiu a partir do Netscape 2.0 (1995), IE 3.0 (1996), AOL 3.0 (1996) e Opera 3.0 (1997)
Depois disso, o Netscape 4.0 (
document.layers) e o IE 4.0 (document.all) usaram modelos diferentesO primeiro DOM padrão foi o W3C DOM Level 1 (1998), com suporte parcial no IE 5.0 (1999) e suporte completo a partir do Konqueror 2.0 (2000) e Netscape 6.0 (2000)
Safari 1.0 (2003), Firefox 1.0 (2004) e Chrome 1.0 (2008) já nasceram com suporte ao DOM padrão, e hoje seguem o WHATWG DOM Living Standard
Como interpreta e renderiza diretamente o texto HTML, o uso de RAM é muito baixo
Projeto excelente
Para leitores do HN, vale ver junto High-Performance Browser Networking e Every Layout
Ambos são ótimos materiais que tratam em profundidade de desempenho web e estrutura de CSS
No capítulo 4, consegui entender a estrutura de frames do TLS, e isso me ajudou a depurar problemas de latência no meu emprego anterior
A parte sobre os trade-offs de ajustar o tamanho dos frames TLS também foi interessante
Talvez eu não use isso com frequência na prática, mas foi bom saber que esse tipo de ajuste fino em nível de rede é possível
É uma abordagem interessante, como experimentar browser.engineering sem precisar instalar nada
Ao mostrar exemplos de navegador e servidor, acho que ficaria mais fácil de entender se fossem adicionados ícones visuais (por exemplo, desktop/servidor)
Por enquanto estou reunindo feedback, e a sugestão dos ícones é boa, então vou considerar
Gostei muito e já favoritei
Mas senti falta do processo de carregamento de recursos como imagens, folhas de estilo e scripts com base em HTML/DOM
Essa parte é importante para entender por que às vezes o estilo da página quebra ou imagens não aparecem
Estou pensando em como adicionar esses blocos sem deixar tudo complexo
Quando a janela do navegador fica estreita (menos de 1170px), a seção de índice fica sobreposta ao conteúdo
Seria bom refinar um pouco mais a lógica de parsing de URL
A maioria dos usuários provavelmente não terá problema, mas o navegador também trata de forma especial quando é inserido um esquema de protocolo diferente de
https://ouhttp://Seria bom capturar esses casos
Referência: List of URI schemes
Projeto excelente
Fico curioso se há planos de adicionar como próximo passo mais detalhes do processo de reflow
É uma pena que mais da metade da página esteja dedicada a requisições de rede
Na prática, a parte realmente complexa do navegador está no pipeline de parsing e renderização
Como eu não sabia em qual seção deveria me aprofundar, publiquei primeiro e agora estou colhendo feedback
Talvez seja uma pergunta meio fora de lugar, mas fiquei pensando: e se eliminássemos completamente a consulta DNS e tudo funcionasse só com nomes de domínio legíveis por humanos?
A ideia seria transformar a internet inteira em um grande switch
Lembro de ter visto um texto de um fundador da Tailscale com uma ideia parecida
Belo trabalho