Você sabe o que acontece quando você digita google.com no seu navegador? Neste artigo, explicarei como funciona o navegador nos bastidores. Certamente, você deve saber que os navegadores da Web são os softwares mais utilizados. Dessa forma, como um bom programador, você deve saber como funcionam os navegadores.
A principal função de um navegador é apresentar o recurso da web que você escolher, solicitando-o ao servidor e exibindo-o na janela do navegador.
O recurso geralmente é um documento HTML, mas também pode ser um PDF, uma imagem ou algum outro tipo de conteúdo. A localização do recurso é especificada pelo usuário usando um URI (Uniform Resource Identifier).
Certamente, a forma como o navegador interpreta e exibe os arquivos HTML é especificada nas especificações HTML e CSS. Dessa forma essas especificações são recomendações da organização W3C (World Wide Web Consortium), que é a organização de padrões para a web.
Durante anos, os navegadores obedeceram apenas a uma parte das especificações e desenvolveram suas próprias extensões. Isso causou sérios problemas de compatibilidade para os autores da web. Hoje, a maioria dos navegadores está mais ou menos em conformidade com as especificações.
As interfaces de usuário do navegador têm muito em comum entre si. Entre os elementos comuns da interface do usuário estão:
- Barra de endereços para inserir um URI
- Botões para trás e para a frente
- Opções de favoritos
- Botões de atualização e parada para atualizar ou interromper o carregamento de documentos atuais
- Botão inicial que leva você para sua página inicial
Curiosamente, a interface de usuário do navegador não é especificada em nenhuma especificação formal, apenas vem de boas práticas moldadas ao longo de anos de experiência e por navegadores imitando mutualmente.
A especificação HTML5 não define os elementos de interface do usuário que um navegador deve ter, mas lista alguns elementos comuns.
Entre eles estão a barra de endereço, a barra de status e a barra de ferramentas. Existem, é claro, recursos exclusivos de um navegador específico, como o gerenciador de downloads do Firefox.
Veja também:
Estrutura Básica Do HTML
Introdução rápida sobre CSS
Introdução rápida sobre Python
Introdução rápida sobre JavaScript
Os principais componentes do navegador são:
- A interface do usuário: isso inclui a barra de endereço, botão voltar/avançar, menu de favoritos, etc. Todas as partes do navegador são exibidas, exceto a janela onde você vê a página solicitada.
- O mecanismo do navegador: organiza ações entre a interface do usuário e o mecanismo de renderização.
- O motor de renderização: responsável por exibir o conteúdo solicitado. Por exemplo, se o conteúdo solicitado for HTML, o mecanismo de renderização analisa HTML e CSS e exibe o conteúdo analisado na tela.
- Rede: para chamadas de rede, como solicitações HTTP, usando diferentes implementações para diferentes plataformas por trás de uma interface independente de plataforma.
- Backend de interface do usuário: usado para desenhar widgets básicos, como caixas de combinação e janelas. Esse back-end expõe uma interface genérica que não é específica da plataforma. Por baixo, ele usa métodos de interface de usuário do sistema operacional.
- Interpretador de JavaScript. Usado para analisar e executar código JavaScript.
- Armazenamento de dados. Esta é uma camada de persistência. O navegador pode precisar salvar todos os tipos de dados localmente, como cookies. Os navegadores também suportam mecanismos de armazenamento como localStorage, IndexedDB, WebSQL e FileSystem.
É importante observar que navegadores como o Chrome executam várias instâncias do mecanismo de renderização: uma para cada guia. Cada guia é executada em um processo separado. Dessa forma essa parte tema como funciona o navegador é importe aprender, porque é a base do assunto.
O mecanismo de renderização
No tema: como funciona o navegador. Inegavelmente o entendimento do mecanismo de renderização faz com que você perceba como a tela exibe os elementos renderizados.
Dessa maneira, a responsabilidade do motor de renderização é bem… Renderização, que é a exibição do conteúdo solicitado na tela do navegador.
Por padrão, o mecanismo de renderização pode exibir documentos e imagens HTML e XML. Pode exibir outros tipos de dados via plug-ins ou extensão; por exemplo, exibir documentos PDF usando um plug-in do visualizador de PDF.
No entanto, vamos nos concentrar no caso de uso principal: exibir HTML e imagens que, por sua vez, são formatadas usando CSS.
Motores de renderização
Diferentes navegadores usam diferentes mecanismos de renderização: o Internet Explorer usa o Trident, o Firefox usa o Gecko, o Safari usa o WebKit. Chrome e Opera (a partir da versão 15) usam Blink, um fork do WebKit.
O WebKit é um mecanismo de renderização de código aberto que começou como um mecanismo para a plataforma Linux e foi modificado pela Apple para suportar Mac e Windows. Veja webkit.org para mais detalhes.
O mecanismo de renderização começará a obter o conteúdo do documento solicitado da camada de rede. Isso será geralmente feito em pedaços de 8kB.
Antes de tudo, o mecanismo de renderização começará a analisar o documento HTML e converterá os elementos em nós DOM em uma árvore chamada “árvore de conteúdo”.
O mecanismo analisará os dados de estilo, tanto em arquivos CSS externos quanto em elementos de estilo. As informações de estilo junto com as instruções visuais no HTML serão usadas para criar outra árvore: a árvore de renderização.
A árvore de renderização contém retângulos com atributos visuais como cor e dimensões. Dessa forma a exibição dos retângulos precisa que ele estejam na ordem certa.
Após a construção da árvore de renderização ela passa por um processo de “layout”.
Isso significa dar a cada nó as coordenadas exatas onde ele deve aparecer na tela. O próximo estágio é a pintura – a árvore de renderização será atravessada e cada nó será pintado usando a camada de back-end da interface do usuário.
É importante entender que este é um processo gradual. Para uma melhor experiência do usuário, o mecanismo de renderização tentará exibir o conteúdo na tela o mais rápido possível.
O mecanismo de renderização não espera a análise de todo o HTML antes de iniciar a construção e o layout da árvore de renderização. Por isso a análise e exibição de um parte do conteúdo será feita, enquanto o processo continua com o restante do conteúdo que continua vindo da rede.
Análise
Depois que o navegador recebe o primeiro bloco de dados, ele pode começar a analisar as informações recebidas. A análise é a etapa que o navegador executa para transformar os dados recebidos pela rede no DOM e CSSOM, dessa forma o renderizador usa para pintar uma página na tela.
O DOM é a representação interna da marcação para o navegador. O DOM também é exposto, podendo ser manipulado por diversas APIs em JavaScript.
Mesmo que o HTML da página de solicitação seja maior que o pacote inicial de 14 KB, o navegador começará a analisar e tentar renderizar uma experiência com base nos dados que possui.
É por isso que é importante para a otimização do desempenho da web incluir tudo o que o navegador precisa para começar a renderizar uma página, ou pelo menos um modelo da página – o CSS e o HTML necessários para a primeira renderização – nos primeiros 14 kilobytes.
Mas antes que qualquer coisa seja renderizada na tela, o HTML, CSS e JavaScript precisam ser analisados.
Construindo a árvore DOM
Descrevemos cinco etapas no caminho crítico de renderização.
A primeira etapa é processar a marcação HTML e construir a árvore DOM. A análise de HTML envolve tokenização e construção de árvore.
Os tokens HTML incluem tags de início e fim, bem como nomes e valores de atributos. Se o documento estiver bem formado, a análise será direta e mais rápida.
O analisador analisa a entrada tokenizada no documento, construindo a árvore do documento.
A árvore DOM descreve o conteúdo do documento. O elemento <html> é a primeira tag e o nó raiz da árvore do documento.
A árvore reflete os relacionamentos e hierarquias entre diferentes tags. Tags aninhadas em outras tags são nós filhos.
Quanto maior o número de nós DOM, mais tempo leva para construir a árvore DOM.
Quando o analisador encontrar recursos não bloqueantes, como uma imagem, o navegador solicitará esses recursos e continuará analisando.
A análise pode continuar quando um arquivo CSS é encontrado, mas as tags <script> — principalmente aquelas sem um atributo async ou defer — bloqueiam a renderização e pausam a análise de HTML.
Embora o verificador de pré-carregamento do navegador acelere esse processo, scripts excessivos ainda podem ser um gargalo significativo.
Construindo o CSSOM
A segunda etapa no caminho crítico de renderização é processar CSS e construir a árvore CSSOM. O modelo de objeto CSS é semelhante ao DOM. O DOM e o CSSOM são ambos árvores.
São estruturas de dados independentes. O navegador converte as regras CSS em um mapa de estilos que ele pode entender e trabalhar.
O navegador passa por cada conjunto de regras no CSS, criando uma árvore de nós com relacionamentos pai, filho e irmão com base nos seletores CSS.
Assim como no HTML, o navegador precisa converter as regras CSS recebidas em algo com o qual possa trabalhar. Portanto, ele repete o processo de HTML para objeto, mas para o CSS.
A árvore CSSOM inclui estilos da folha de estilos do agente do usuário. Desse modo, o navegador começa com a regra mais geral aplicável a um nó e refina recursivamente os estilos computados aplicando regras mais específicas. Em outras palavras, ele cascateia os valores da propriedade.
Construir o CSSOM é muito, muito rápido e não é exibido em uma cor única nas ferramentas de desenvolvedor atuais.
Em vez disso, o “Recalcular Estilo” nas ferramentas do desenvolvedor mostra o tempo total necessário para analisar o CSS, construir a árvore do CSSOM e calcular recursivamente os estilos computados.
Em termos de otimização de desempenho da Web, há frutos mais baixos, pois o tempo total para criar o CSSOM é geralmente menor do que o tempo necessário para uma pesquisa de DNS.
Renderizar
As etapas de renderização incluem estilo, layout, pintura e, em alguns casos, composição. As árvores CSSOM e DOM criadas na etapa de análise e combinam com uma árvore de renderização que usa calculo no layout de cada elemento visível, assim a tela os pintam.
Em alguns casos, as próprias camadas e compostos promove o próprio conteúdo, melhorando o desempenho pintando partes da tela na GPU em vez da CPU, liberando o thread principal.
Estilo
A terceira etapa no caminho crítico de renderização é combinar o DOM e o CSSOM em uma árvore de renderização. Assim, a construção da árvore de estilos computada, ou árvore de renderização, começa com a raiz da árvore DOM, percorrendo cada nó visível.
Certamente as Tags que não serão exibidas, como o <head> e seus filhos e quaisquer nós com display: none, como o script { display: none; } que você encontrará nas folhas de estilo do agente do usuário, não são incluídos na árvore de renderização, pois não aparecerão na saída renderizada.
Nós com visibilidade: ocultos aplicados são incluídos na árvore de renderização, pois ocupam espaço. Como não fornecemos nenhuma diretiva para substituir o padrão do agente do usuário, o nó de script em nosso exemplo de código acima não será incluído na árvore de renderização.
Cada nó visível tem suas regras CSSOM aplicadas a ele. A árvore de renderização contém todos os nós visíveis com conteúdo e estilos computados — combinando todos os estilos relevantes para cada nó visível na árvore DOM e determinando, com base na cascata CSS, quais são os estilos computados para cada nó.
Esquema
A quarta etapa no caminho crítico de renderização é executar o layout na árvore de renderização para calcular a geometria de cada nó.
Layout é o processo pelo qual a largura, altura e localização de todos os nós na árvore de renderização são determinados, mais a determinação do tamanho e posição de cada objeto na página.
O refluxo é qualquer determinação subsequente de tamanho e posição de qualquer parte da página ou de todo o documento.
Uma vez que a árvore de renderização é construída, o layout começa. A identificação e exibição dos nós quem determina é a árvore de renderização (mesmo se invisíveis) junto com seus estilos calculados, mas não as dimensões ou localização de cada nó.
Para determinar o tamanho e a localização exatos de cada objeto, o navegador inicia na raiz da árvore de renderização e a percorre.
Na página da web, quase tudo é uma caixa. Diferentes dispositivos e diferentes preferências de desktop significam um número ilimitado de diferentes tamanhos de janela de visualização.
Nesta fase, considerando o tamanho da janela de visualização, o navegador determina quais serão as dimensões de todas as diferentes caixas na tela.
Tomando o tamanho da viewport como base, o layout geralmente começa com o corpo, estabelecendo as dimensões de todos os descendentes do corpo, com as propriedades do modelo de caixa de cada elemento, fornecendo espaço reservado para elementos substituídos dos quais não conhece as dimensões.
A primeira vez que o tamanho e a posição dos nós, são determinados dar-se o nome de layout.
Os recálculos subsequentes do tamanho e local do nó recebe o nome de refluxos.
Em nosso exemplo, suponha que o layout inicial ocorra antes que a imagem seja retornada. Como não declaramos o tamanho da nossa imagem, haverá um reflow assim que o tamanho da imagem for conhecido.
Pintar
A última etapa no caminho crítico de renderização é pintar os nós individuais na tela, cuja primeira ocorrência tem com nome a primeira pintura significativa.
Na fase de pintura ou rasterização, o navegador converte cada caixa calculada na fase de layout em pixels reais na tela.
Inegavelmente a pintura envolve desenhar todas as partes visuais de um elemento na tela, incluindo texto, cores, bordas, sombras e elementos substituídos, como botões e imagens. O navegador precisa fazer isso super-rápido.
Para garantir rolagem e animação suaves, tudo o que ocupa o encadeamento principal, incluindo o cálculo de estilos, juntamente com o refluxo e a pintura, deve levar menos de 16,67 ms para o navegador.
Em 2048 X 1536, o iPad tem mais de 3.145.000 pixels para serem pintados na tela. São muitos pixels que precisam ser pintados muito rapidamente.
Para garantir que a repintura possa ser feita ainda mais rápido do que a pintura inicial, o desenho na tela é geralmente dividido em várias camadas. Se isso ocorrer, a composição é necessária.
A pintura pode dividir os elementos na árvore de layout em camadas. Dessa forma, a promoção de conteúdo em camadas na GPU (em vez do thread principal na CPU) melhora o desempenho de pintura e repintura.
Existem propriedades e elementos específicos que instanciam uma camada, incluindo <video> e <canvas>, e qualquer elemento que tenha as propriedades CSS de opacity, uma transformação 3D, will-change e algumas outras.
Esses nós serão pintados em sua própria camada, juntamente com seus descendentes, a menos que um descendente precise de sua própria camada por um (ou mais) dos motivos acima.
As camadas melhoram o desempenho, mas são caras quando se trata de gerenciamento de memória, portanto, não devem ser usadas em excesso como parte das estratégias de otimização de desempenho da Web.
Quando as seções do documento são desenhadas em camadas diferentes, sobrepostas umas às outras, a composição é necessária para garantir que sejam desenhadas na tela na ordem correta e que o conteúdo seja renderizado corretamente.
À medida que a página continua a carregar ativos, podem ocorrer refluxos (lembre-se de nossa imagem de exemplo que chegou atrasada).
Além disso, um refluxo desencadeia uma repintura e uma recomposição. Dessa maneira, se tivéssemos definido o tamanho de nossa imagem, nenhum reflow seria necessário, e apenas a camada que precisava ser repintada seria repintada e composta, se necessário.
Mas não incluímos o tamanho da imagem! Quando a imagem é obtida do servidor, o processo de renderização volta para as etapas de layout e reinicia a partir daí.
Interatividade
Assim que o tópico principal terminar de pintar a página, você pensaria que estaríamos “tudo pronto”. Isso não é necessariamente o caso.
Dessa forma, se o carregamento incluir JavaScript, que foi adiado corretamente e executado apenas após o disparo do evento onload, o encadeamento principal pode estar ocupado e não disponível para rolagem, toque e outras interações.
Certamente, o tempo até a interação (TTI) é a medida de quanto tempo levou desde a primeira solicitação que levou à pesquisa de DNS e à conexão SSL até quando a página é interativa — interativa sendo o ponto no tempo após a primeira exibição de conteúdo em que a página responde a interações do usuário dentro de 50ms.
Se o encadeamento principal estiver ocupado analisando, compilando e executando JavaScript, ele não estará disponível e, portanto, não poderá responder às interações do usuário em tempo hábil (menos de 50 ms).
Em nosso exemplo, talvez a imagem tenha sido carregada rapidamente, mas talvez o arquivo anotherscript.js tenha 2 MB e a conexão de rede do nosso usuário esteja lenta.
Nesse caso, o usuário veria a página super rapidamente, mas seria incapaz de rolar sem travar até que o script fosse baixado, analisado e executado.
Esse é o processo por trás dos navegadores, é uma parte um pouco técnico, mas com o tempo fica fácil o entendimento. Então, bons estudos e até a próxima.
Veja o primeiro artigo do Roadmap: Passo a passo de como funciona a internet
Perguntas frequentes
Os navegadores da web se baseiam em diferentes mecanismos do navegador, que lêem o código HMTL e PHP e o apresentam como resultado final. Assim são é um programa de computador projetado essas linguagens. Em outras palavras, o navegador permite o usuário acessar site e páginas.
Os mais populares são: Chrome, Internet Explorer, Firefox e Safari.
O Document Object Model (DOM – Modelo de Objeto de Documento) é uma interface de programação independente de plataforma e linguagem que permite que programas e scripts acessem e modifiquem o conteúdo, a estrutura e a aparência de documentos HTML, XHTML e XML. O DOM fornece uma visão estruturada do documento com base no código HTML na forma de uma árvore.
É formada por um grupo de nós e objetos conectados pelos relacionamentos “pai-filho. Dessa forma, a árvore é construída de cima para baixo, os links entre os nós são determinados com base no fato de que cada elemento no documento HTML está incorporado em algum outro elemento, exceto a raiz superior (da árvore). Um elemento que contém outros elementos é um pai para eles, e os elementos incorporados a ele são seus elementos filhos.
