Como melhorar a velocidade da página do início ao fim (guia avançado)

67

A velocidade da página é um assunto complexo. Muitos dos artigos existentes fornecem uma lista de ações a serem executadas ou plug-ins a serem instalados para ajudar com diferentes aspectos da velocidade. Tudo bem, mas nem todos os sites são iguais. Portanto, neste post, ajudarei você a entender como funciona a velocidade da página e quais ações devem ser executadas em seu site específico.

Com isso dito, se você não é técnico e está apenas esperando instalar um plug-in/módulo para acelerar seu site, aqui estão alguns que devem ajudar:

WordPress:

• WP Rocket (pago)  + um plug-in de otimização de imagem ou:
• Autoptimize  + um plug-in de cache

DrupalName

• AdvAgg  + um módulo de otimização de imagem

Agora, de volta aos negócios. Aqui está tudo o que vou cobrir:

• O que é velocidade da página?
• Por que você deve se preocupar com a velocidade da página
• Quão rápido minha página deve carregar?
• Como uma página é construída
• Ferramentas e testes de velocidade da página
• Estimando o impacto das mudanças

A velocidade da página é uma medida da quantidade de tempo que leva para uma página da Web carregar depois de ser solicitada por um navegador. É difícil atribuir um único número à velocidade da página porque muitas métricas capturam elementos do carregamento da página de maneiras diferentes, para finalidades diferentes e com condições de teste diferentes.

Houve um foco renovado na velocidade da página do Google recentemente, com a velocidade móvel se tornando um fator de classificação , um relatório de velocidade  no Google Search Console e o Chrome anunciando que eles podem sinalizar sites lentos , mas você sabia que a velocidade da página tem sido um fator de classificação para o Google desde 2010 ?

Aqui estão as razões pelas quais você deve se importar:

• Impacta a experiência do usuário . Você quer que os visitantes tenham uma experiência rápida e tranquila. Qualquer atraso ou atraso em suas ações é perceptível.
• Análise de Impactos . De um modo geral, um site mais rápido registrará mais visitantes porque a tag de análise será carregada mais cedo. Se uma pessoa sair antes que a tag seja disparada, ela não será registrada no sistema de análise.
• SEO ? A atualização de velocidade afeta apenas os sites mais lentos de acordo com o anúncio oficial .

Existem muitos estudos mostrando que, se você aumentar a velocidade da página, verá aumentos em coisas como tráfego orgânico, taxa de cliques para visitar em anúncios, mais visitantes em geral e muitos outros benefícios. O WPO Stats  tem muitos estudos de exemplo sobre melhorias na velocidade da página.

No entanto, advertirei que muitos desses estudos podem ser um pouco enganosos. A menos que você fosse extremamente lento antes, o Google diz que melhorar a velocidade da página não deve afetar sua classificação.

Então, por que você pode ver mais visitantes?

A resposta é que a tag de análise provavelmente foi disparada mais cedo do que antes e conseguiu registrar mais pessoas antes que elas saíssem de uma página.

Não há limite oficial . Uma das recomendações comuns é que seu site carregue em menos de três segundos. Isso provavelmente vem de um estudo do Google  que diz que 53% dos visitantes móveis deixam uma página que leva mais de três segundos para carregar.

Essa recomendação provavelmente também se baseia na métrica do índice de velocidade, sobre a qual falaremos mais adiante, mas isso é apenas minha especulação com base no que era uma medida popular na época do estudo. Não acredito que o Google tenha mencionado uma métrica específica ao fornecer um número para a velocidade da página. Normalmente, as recomendações dos representantes do Google são genéricas como “tornar os sites rápidos para os usuários” ou “tornar os sites o mais rápido possível”.

Para entender como melhorar a velocidade da sua página, você precisa saber como um navegador constrói uma página. Para isso, examinaremos principalmente os gráficos em cascata para ver quais recursos estão sendo carregados. Você também pode ver isso em seu navegador clicando com o botão direito do mouse > Inspecionar > e abrindo a guia Rede ao carregar uma página.

Estabelecendo Conexões

O verde, laranja e roxo abaixo representam o tempo que leva para estabelecer uma conexão com o site. Vou falar sobre cada cor abaixo e o que ela representa.

DNS (Verde)

Domain Name System (DNS) é considerado o catálogo telefônico da web. Você dá ao seu navegador um nome de site e ele verifica com um servidor DNS para obter um endereço IP (uma etiqueta de localização) informando onde o site está hospedado. É como armazenar um contato no seu telefone, então você só precisa saber o nome e não o número do telefone.

Na maioria das vezes, seu DNS estará com seu registrador de domínio (onde você comprou o domínio) ou com sua rede de entrega de conteúdo (CDN).

É importante ressaltar que nem todos os provedores de DNS são criados iguais. Se cada milissegundo for importante para você, considere usar um provedor de DNS diferente. De acordo com o DNSPerf , o Cloudflare tem uma velocidade média de consulta de 12,6 ms, enquanto outros como GoDaddy (46,04 ms) e Rackspace (90,38 ms) são mais lentos em média. No entanto, esses números não são uma representação totalmente precisa, pois o DNS pode ser armazenado em cache (armazenado temporariamente) no navegador quando você já visitou um site. A quantidade de tempo que é armazenada em cache é chamada de TTL (Time to Live). Enquanto o cache ainda estiver ativo, o navegador não precisará se conectar ao servidor DNS para saber onde acessar o site.

Conectar (laranja)

É aqui que o navegador estabelece uma conexão com o servidor de hospedagem. Transmission Control Protocol/Internet Protocol (TCP/IP) é complicado, mas pense em como você começa a trabalhar. Provavelmente não é uma linha reta; você tem que fazer curvas e haverá áreas com maior tráfego. Você pode até mesmo redirecionar ou fazer algumas curvas erradas. É mais ou menos assim que funciona; é o roteamento do seu navegador para o servidor e vice-versa.

Se o tempo de conexão for longo, pode ser um dos muitos problemas. Em conexões instáveis, pode ocorrer perda de pacote e terá que ser reenviado. Isso é como perder a curva em uma rotatória e ter que dar a volta novamente. O problema também pode estar no roteamento da solicitação pela rede. Quantos saltos ele precisa dar, a distância que ele precisa percorrer, quanto tráfego há na rede são semelhantes a quantas voltas você precisa fazer, a que distância do trabalho você está e quantos outros carros estão na estrada isso pode atrasá-lo. Há também limitação de taxa e capacidade de conexão no servidor, o que seria semelhante a um túnel que permite apenas tantos carros por vez.

Muitos desses problemas são resolvidos diminuindo a distância até o servidor e usando um roteamento mais inteligente, o que muitos CDNs podem fazer. Com uma rede de servidores em todo o mundo, os visitantes geralmente podem se conectar a um próximo. Alguns provedores de CDN também gerenciam grandes quantidades de solicitações de internet e podem ver em tempo real onde pode haver gargalos (tráfego). Se eles virem uma opção mais rápida, poderão redirecionar o tráfego – exatamente como um GPS redirecionaria você em um engarrafamento.

Secure Sockets Layer (SSL) (roxo)

Para sites que estabelecem uma conexão segura ( HTTPS ), é aqui que o navegador e o servidor concordam com a versão do protocolo TLS (Transport Layer Security), o ciphersuite (nível de segurança) e verificam o certificado (para garantir que o site é o um diz que é).

Você pode estar pensando que pode tornar seu site mais rápido simplesmente não usando HTTPS. Isso é parcialmente verdade – pelo menos para a parte da conexão. Mas há outros benefícios em estar em HTTPS, como o fato de que os navegadores não permitem que você use HTTP/2 (H2) sem HTTPS. O H2 tem algumas vantagens como conexões persistentes, portanto não precisa ficar abrindo uma nova conexão para arquivos no mesmo servidor. Os cabeçalhos dessas solicitações também são menores do que em HTTP/1.1 e vários arquivos podem ser transferidos simultaneamente. Na maioria dos casos, os sites que usam HTTPS e H2 serão mais rápidos do que os sites em HTTP.

Geralmente, os ganhos mais significativos que você obterá aqui vêm da atualização do seu protocolo (TLS 1.3 é mais rápido que o TLS 1.2, por exemplo) e da implementação do HTTP Strict Transport Security (HSTS), que informa ao navegador para sempre usar uma conexão segura. O navegador altera as solicitações de HTTP para HTTPS sem precisar entrar em contato com o servidor e fazer um redirecionamento. Na imagem abaixo, o redirecionamento de HTTP para HTTPS e o tempo que levava seriam eliminados com o uso do HSTS.

Você pode até querer usar HTTP/3  para conexões ainda mais rápidas. No entanto, o suporte para esse protocolo ainda está nos estágios iniciais e, pelo menos no momento em que escrevo, provavelmente ainda não é uma opção viável.

Baixando e Processando HTML

O código HTML de uma página é o que inicialmente é baixado por um navegador. Esta é a informação que você vê quando clica com o botão direito do mouse em um site e vai para “Exibir fonte da página”. Depois que uma conexão é estabelecida e o navegador obtém o primeiro bit de informação do servidor, chegamos ao Time To First Byte (TTFB), que é a medida típica para o tempo de resposta inicial. Conforme representado pelas linhas laranja abaixo, este é o tempo desde o início da solicitação HTML (azul claro) até o momento em que o download do HTML começa (azul escuro).

Se houver um atraso para o TTFB, pode ser devido a consultas de banco de dados, recursos do servidor, espera pela conclusão de um SSR (Server Side Render) ou outras coisas normalmente envolvidas na criação de conteúdo dinâmico. O tempo de download dependerá de coisas como a conexão e o tamanho do arquivo.

É também aqui que o navegador também começa a construir uma página. Quando o HTML é baixado, o navegador o analisa no Document Object Model (DOM), que é como um computador entende a estrutura do conteúdo. Esse processo de análise usa o thread principal do navegador para processar as ações do usuário e pintar a página, executar JavaScript e executar layout, refluxos e coleta de lixo. Por enquanto, apenas saiba que esse thread principal existe e lida com várias tarefas diferentes. Nós vamos cobrir isso um pouco mais tarde.

Se você observar uma lacuna entre o HTML e a próxima solicitação, a causa mais provável é que a CPU esteja ocupada processando o HTML para criar o DOM. Como é a CPU, isso depende novamente do dispositivo que está sendo usado, portanto, você pode testar com um dispositivo mais potente para ver se essa lacuna ainda existe.

Para o HTML e outros tipos de arquivo como CSS e JavaScript, você pode reduzir o tempo usando menos código, minificação para remover caracteres desnecessários como comentários e espaços em branco do código e compactação para reduzir o tamanho dos arquivos. O objetivo é tornar o download do arquivo menor para que essa parte do carregamento seja mais rápida. No entanto, não há apenas uma maneira de minificação e compactação. Em muitos casos, isso é tratado pelo CDN ou pelo servidor (Apache ou Nginx são servidores comuns) ou por um plug-in/módulo/pacote. Você pode encontrar mais informações sobre como implementar compactação aqui  e minificação aqui .

Manipulando Conexões Adicionais

Quando o HTML for baixado, as referências a outros arquivos e outros servidores serão processadas e novas conexões serão iniciadas. Normalmente, é aqui que outros arquivos, como JavaScript, CSS, Imagens e Fontes, são adicionados à mistura. As coisas podem ficar loucas aqui, pois alguns arquivos fazem referência a outros arquivos e começamos a encadear conexões e downloads de arquivos. Dê uma olhada no mapa de solicitação abaixo para Forbes.com. Cada ponto é uma solicitação de arquivo individual e cada linha é onde um arquivo está referenciando outro arquivo que deve ser baixado. Ao todo são 363 pedidos em 128 conexões.

Use o mesmo servidor para solicitações quando possível

Costumava ser uma prática recomendada hospedar recursos em domínios sem cookies que não eram iguais ao domínio principal e, às vezes, havia um benefício em usar vários domínios (um processo chamado fragmentação de domínio) devido aos limites de solicitação de conexão definidos pelo navegador.

Desde o HTTP/2, essa não é uma prática recomendada. Você deve usar o mesmo servidor para solicitações, se possível.

Por exemplo, considere cdn.ahrefs.com  no gráfico em cascata abaixo.

Se esse arquivo estivesse hospedado em ahrefs.com, ele nem precisaria fazer a conexão. Está atrasado na hora de fazer a conexão DNS, conectar e negociar o handshake de segurança. Sem os obstáculos extras para percorrer, teríamos o arquivo mais cedo, o que significa que a página carregaria ainda mais rápido.

No entanto, embora a auto-hospedagem de muitos arquivos, como fontes, possa levar a ganhos, pode haver outras compensações, como armazenamento em cache (armazenar uma cópia de um arquivo), em que os navegadores às vezes podem ter recursos comuns armazenados em cache. Por exemplo, se eu visitei um site que chamou uma fonte do Google Fonts e depois fui para outro site usando a mesma fonte, talvez eu já tenha esse arquivo armazenado em cache localmente e não precise baixá-lo novamente.

Use pré-conexão ou pré-busca de DNS (se você usar outro servidor)

Se for usar um servidor diferente, conecte-se previamente a servidores que contenham arquivos necessários no início do carregamento da página. Isso fará a conexão com outro servidor mais cedo do que normalmente aconteceria. Veja abaixo como uma das conexões para a Amazon começa antes mesmo do processamento do HTML terminar.

Exemplo de código:
<link rel="preconnect" href="https://site.com">

Há também pré-busca de DNS se você quiser apenas lidar com essa parte da conexão antecipadamente. A parte verde (DNS) se conectaria antes, mas o resto da conexão aconteceria depois. DNS-prefetch tem melhor suporte  do que preconnect , mas se você observar as estatísticas de uso atuais, a diferença seria insignificante. A pré-conexão geralmente é melhor se você souber que algo desse servidor precisa ser carregado antecipadamente para que a página funcione. No entanto, como a pré-conexão exige mais trabalho para roteamento e segurança (o laranja e o roxo), ela também exigirá um pouco mais de recursos desde o início.

Exemplo de código:
<link rel="dns-prefetch" href="//asset1.com">

Como os navegadores renderizam uma página

Antes de continuarmos e discutirmos as opções de otimização, acho melhor entender um pouco sobre como um navegador renderiza uma página. Temos outros arquivos chegando agora, como CSS, JavaScript, imagens e fontes, e o navegador precisa transformá-los, junto com o HTML, em algo útil. Este é um processo dinâmico com novos arquivos sendo introduzidos, baixados, analisados ​​e coisas sendo reorganizadas constantemente para construir a página. Esse processo é comumente chamado de Caminho crítico de renderização e tem a seguinte aparência:

1. O HTML é processado na árvore DOM que mencionamos anteriormente
2. O CSS é analisado no CSS Object Model (CSSOM), que informa ao navegador como tudo é estilizado, preenchido, colorido, dimensionado, etc.
3. O CSSOM + DOM juntos formam o que é chamado de Render Tree .
4. O layout acontece, que é o processamento de onde cada elemento estará dentro da viewport do navegador com base no que está na árvore de renderização.
5. Os pixels são pintados na tela para que, em vez de uma tela branca, você veja cores, formas, texto e imagens.

O objetivo deve ser obter os elementos necessários o mais cedo possível para construir a visualização inicial o mais rápido possível. O tempo de carregamento visível é a percepção das pessoas sobre a velocidade de uma página, ou seja, quanto tempo o conteúdo aparece na tela para elas. O que mais afeta isso é como os recursos são carregados. Geralmente é responsabilidade do CMS ou JavaScript Framework ajudar o navegador a priorizar quando/o que/como os recursos devem ser carregados em que ordem para fazer o site parecer mais rápido. Mais sobre isso daqui a pouco.

Você também deseja manter as coisas simples e evitar cálculos complexos e muitas alterações durante a fase de layout. O Google tem um guia mais focado no desenvolvedor para isso aqui e outro para simplificar o processo de pintura .

Métricas de carga visual:

• First Paint (FP)  – o navegador renderiza qualquer coisa pela primeira vez.
• First Contentful Paint (FCP) – o navegador renderiza algo do DOM (Document Object Model), que pode ser texto, uma imagem, etc.
• First Meaningful Paint (FMP)  – os elementos mais importantes carregados visualmente.
• Largest Contentful Paint (LCP)  – maior elemento carregado acima da dobra.
• Visualmente completa  – a página é carregada visualmente.
• Índice de velocidade – uma pontuação calculada para a carga visual que leva em consideração vários pontos no tempo.
• Deslocamento de layout cumulativo (CLS)  – Mede quantos elementos se movem na viewport durante o carregamento ou quão estável é o layout. Há um bom guia para as causas do CLS aqui .

 

Vendo a carga visual junto com o gráfico em cascata

Na seção Summary em WebPageTest , se você habilitou a gravação, deverá ter uma coluna Video na tabela principal com “Filmstrip View”. Nesta exibição, a linha vermelha na parte superior com os instantâneos visuais está no mesmo ponto que a linha vermelha na parte inferior da cascata.

Ao mover a linha vermelha para diferentes pontos na carga visual, você poderá ver o que acabou de ser carregado na cascata que pode ter permitido que diferentes elementos fossem exibidos visualmente. Isso pode ajudá-lo a determinar quais arquivos você pode precisar priorizar.

Por exemplo, se você perceber que a maior parte da sua página está carregada, exceto o texto, mas logo depois disso uma fonte é carregada e o texto aparece, isso é uma boa indicação de que a fonte foi necessária para mostrar o texto. Você também poderá dizer quais imagens podem ser necessárias anteriormente com diferentes viewports, simplesmente observando as capturas de tela geradas.

Na parte inferior deste gráfico estão informações adicionais, como utilização da CPU, largura de banda, atividade no encadeamento principal do navegador e interatividade. Todos esses gráficos novamente dependem do dispositivo e do tipo de conexão. As informações podem ser usadas para ajudar a solucionar problemas diferentes. Por exemplo, talvez haja muito download, o que mantém a largura de banda no ponto mais alto. Ou talvez haja um script usando toda a CPU de um determinado dispositivo, o que pode causar atrasos.

CSS do tipo de arquivo

Onde a velocidade da página fica complicada é que, em muitos casos, não há uma maneira certa de fazer as coisas. A maioria dos métodos tem compensações e alguns são mais complexos de implementar e manter. Você precisa decidir o que é mais fácil, rápido e melhor para você em suas circunstâncias.

Olhando para os arquivos CSS, eles bloqueiam a renderização por padrão, o que significa que precisam ser baixados e processados ​​antes que uma página exiba o conteúdo para o usuário. Se você armazenar em cache (armazenar uma cópia do arquivo, abordado posteriormente no artigo), esse arquivo poderá ser reutilizado para carregamentos de página subsequentes. Isso significa que não será necessário baixá-lo novamente e as próximas visualizações serão mais rápidas.

A maioria das ferramentas de velocidade é testada com a primeira visualização, portanto, muito do que você vê em uma ferramenta como o PageSpeed ​​Insights  é representativo de um usuário iniciante que visualiza apenas uma página e não de alguém que visita várias páginas ou volta ao seu site com frequência . Seu objetivo deve ser otimizar a primeira exibição e as exibições subsequentes para os usuários.

Carregando CSS de forma assíncrona

Você deseja carregar um código importante o mais rápido possível, e falaremos sobre algumas opções para isso em um segundo, mas a outra parte disso é que você deseja que o CSS não bloqueie a renderização. Para fazer isso, queremos carregar as folhas de estilo necessárias posteriormente no processo de carregamento como um tipo de mídia diferente, que é aplicado a todos os tipos. Ele está enganando o navegador abusando de como eles lidam com o carregamento de atributos de elementos de link específicos. O que ele vai fazer é carregar o CSS sem bloquear a renderização (porque neste caso, estamos dizendo ao navegador que esta folha de estilo é para impressão e não para esta versão da página), e então aplicar a todos os tipos de mídia (coisas que não são impressos) depois de carregado.

Por exemplo, isto:

<link rel="stylesheet" href="/my.css">

Torna-se isto:

<link rel="stylesheet" href="/my.css" media="print" onload="this.media='all'">

Você pode usar isso com todas as suas referências CSS. A desvantagem é que os usuários podem experimentar alguns flashes/reestilização, pois alguns elementos da página podem ser pintados antes que o CSS seja aplicado. Então, quando o CSS é aplicado, a tela pode mudar onde e como as coisas são exibidas.

Em linha

Inline pega o código necessário para renderizar o conteúdo acima da dobra e o entrega com a resposta HTML em vez de um arquivo separado. Normalmente, essa será a maneira mais rápida de reduzir o tempo necessário para renderizar a visualização inicial.

A maneira mais fácil de pensar sobre isso é pegar partes críticas dos arquivos CSS e JS e colocá-las diretamente no HTML. O HTML inicial demora um pouco mais para baixar e analisar, mas a renderização da página agora pode acontecer antes que todos os outros arquivos sejam baixados.

Inlining provavelmente vai te dar a renderização mais rápida no carregamento inicial da página, mas a compensação tem sido tradicionalmente com o cache. O código carregado no HTML não pôde ser reutilizado do cache, portanto, você normalmente carregaria parte do código duas vezes: uma vez com o HTML e novamente no arquivo normal que normalmente era armazenado em cache. Mas se você inline o código para cada página, isso também significa que as páginas subsequentes também terão código extra. Isso é avançado e envolve o uso de service workers , mas você pode ter inlining e cache . Combinado com tornar o resto do CSS assíncrono, como mencionamos acima, esse é praticamente um estado ideal.

Lembre-se de que você pode minificar o código CSS embutido. Conforme mencionado na seção HTML acima, isso remove alguns dos espaços desnecessários e caracteres extras para tornar o código menor e mais rápido para baixar.

Você provavelmente não deseja inline todo o conteúdo de todos os arquivos. Seja atencioso e inline apenas conteúdo crítico. Você pode tecnicamente incorporar todos os CSS e JS e até mesmo fontes e imagens, mas acabará com um download gigante de HTML em que grande parte do código não é usado. Isso realmente torna seu site mais lento. Se você tiver alguns arquivos menores de apenas alguns KB e quiser inline tudo para eles, provavelmente não há problema em fazê-lo.

CSS crítico embutido em escala:

Você vai querer um sistema automatizado em vez de fazer isso para cada página. Pode fazer sentido inline apenas o CSS para a página inicial nos temas do WordPress, já que normalmente tem uma folha de estilo diferente das outras páginas. Geralmente, haverá algum plug-in/módulo/pacote ou uma versão de Critical ou Critical CSS. Esses pacotes existem para qualquer executor de tarefas ou empacotamento que você esteja usando, como Grunt, Gulp, Webpack ou Framework como React , Angular, Vue, e você pode até encontrar tutoriais específicos para WordPress ou Drupal ou até mesmo páginas codificadas manualmente. Eles enviarão um navegador sem cabeçalho para a página para determinar qual CSS é realmente crítico para o carregamento da página em tamanhos diferentes e fornecerão o código ou dividirão o código em elementos críticos e não críticos para que você possa carregá-los adequadamente . Alguns exemplos:

Grunt:
https://github.com/filamentgroup/grunt-criticalcss
https://www.npmjs.com/package/grunt-critical-css
https://github.com/bezoerb/grunt-critical

Gulp:
https://github.com/addyosmani/critical
https://www.npmjs.com/package/gulp-critical-css

Webpack:
https://github.com/anthonygore/html-critical-webpack-plugin
https://github.com/GoogleChromeLabs/critters
https://github.com/anthonygore/html-critical-webpack-plugin
https:/ /www.npmjs.com/package/critical-css-webpack-plugin

Reagir:
https://www.npmjs.com/package/react-critical-css
https://github.com/addyosmani/critical-path-css-tools
https://github.com/sergei-zelinsky/react- CSS crítico

Angular:
https://github.com/addyosmani/critical-path-angular-demo

Vue:
https://github.com/anthonygore/vue-cli-plugin-critical
https://vuejsdevelopers.com/2017/07/24/critical-css-webpack/

Drupal:
https://www.fourkitchens.com/blog/article/use-gulp-automate-your-critical-path-css/

WordPress:
https://wordpress.org/plugins/wp-criticalcss/

Codificado manualmente:
https://www.sitelocity.com/critical-path-css-generator
https://jonassebastianohlsson.com/criticalpathcssgenerator/

Pré-carregar

Se você não vai embutir o CSS crítico, a próxima melhor opção é sem dúvida usar o Preload. O pré-carregamento busca solicitações no início do carregamento, obtendo recursos essenciais necessários para exibir a página mais rapidamente do que o normal. Pré-carregamento define a prioridade do navegador para ativos pré-carregados como alta e os carrega de forma assíncrona, para que não bloqueiem a renderização. Ele também funciona em domínios.

O navegador dá prioridade a cada solicitação de arquivo. A ideia é obter os arquivos necessários para exibir o conteúdo acima da dobra mais cedo (com uma prioridade mais alta) e adiar aqueles que não são necessários para mais tarde no processo. Você pode ver a prioridade dada aos arquivos na guia Rede no Chrome Dev Tools. Basta clicar com o botão direito do mouse na barra, selecionar Prioridade e adicioná-la como uma coluna.

O que ele fará é pegar um arquivo que pode ter começado a baixar mais tarde e baixá-lo o mais rápido possível. Novamente, o outro benefício é que, onde o arquivo pré-carregado teria bloqueado a renderização antes, esse não será mais o caso.

 

Combinado com o que mencionamos acima para tornar o CSS assíncrono, o pré-carregamento apenas adiciona outra linha destinada a obter o arquivo mais rapidamente, definindo a prioridade do navegador mais alta que o normal. Isso também funcionará para navegadores onde o pré-carregamento não é suportado .

Exemplos de código:

<link rel="preload" href="/my.css" as="style">
<link rel="stylesheet" href="/my.css" media="print" onload="this.media='all'">

Escolhendo quais arquivos pré-carregar

Normalmente, você terá o arquivo de tema principal que contém grande parte do CSS do site. Os desenvolvedores geralmente nomeiam isso de acordo com o tema, ou o chamam de “estilo” ou, às vezes, o nomeiam do próprio site. Se você tiver problemas para identificar este arquivo ou acreditar que outros arquivos também precisam ser pré-carregados, a maneira mais fácil de verificar é usar o recurso de bloqueio de solicitação nas Ferramentas de desenvolvimento do Chrome. Abra a guia Rede e carregue uma página para ver os arquivos solicitados. Você pode clicar com o botão direito neles para adicioná-los à lista de bloqueio. Ao recarregar uma página, se ela ainda parecer normal, provavelmente você não bloqueou um arquivo necessário para o conteúdo acima da dobra. Quando você obtém um desses que altera a aparência da página, é uma indicação de que é necessário renderizar o conteúdo acima da dobra e é um arquivo que você deseja pré-carregar.

O que você deve saber sobre o pré-carregamento

1. Você precisa de fontes cruzadas ou obterá uma carga dupla do arquivo.
2. Você ainda precisa das chamadas de arquivo normais para JS + CSS, portanto, não as exclua.
3. Você pode pré-carregar uma fonte mesmo que ela seja chamada em outro arquivo, como um arquivo CSS.
4. Tenha cuidado com o quanto você pré-carrega. Você pode ter problemas ao tentar pré-carregar muitos arquivos.

Push do servidor

Isso fazia parte da especificação HTTP/2 (H2). Ele permite que um servidor entregue um arquivo sem que ele seja solicitado. Então, em vez de uma cadeia que pode ser HTML > CSS > Fonte, isso permite que um site diga que vou precisar dessa fonte, basta enviá-la.

O Server Push é problemático e eu normalmente não o recomendo, mas se você for um grande desenvolvedor ou tiver acesso a um, pode tentar. Ele solicita arquivos do servidor na mesma conexão da solicitação de página. O push do servidor pode carregar ativos duas vezes. Há uma solução alternativa usando cookies e verificando se você já enviou ativos aos usuários, mas é uma implementação complexa. Há outro problema envolvendo problemas de conexão que podem fazer com que os arquivos não sejam carregados. Com todo o trabalho extra, você ainda pode não ver ganhos significativos sobre o pré-carregamento porque os navegadores verificam o cache da página (onde está o pré-carregamento) antes do push cache.

JavaScript do tipo de arquivo

O JavaScript também pode ser complexo, com muitas opções e muitas considerações. Às vezes é usado para fornecer funcionalidade, às vezes é usado para extrair o conteúdo principal e às vezes é usado até mesmo para fazer alterações no CSS. Além disso, determinado código pode precisar de outro código para funcionar corretamente. Essas são conhecidas como dependências, e alterar a forma como o JavaScript é carregado pode acabar quebrando algumas funcionalidades da página.

Se o JavaScript desempenha um papel crítico no conteúdo ou no estilo da página, ou se é o sistema principal – como é o caso de muitos frameworks JavaScript – então muitas das mesmas regras do CSS se aplicam tanto quanto inlining e pré-carregamento. No entanto, você também tem a opção de Server Side Rendering (SSR) . Isso processa o código e renderiza um instantâneo. Por exemplo, se o JavaScript for usado para preencher itens na página ou para o menu, você pode querer essas informações mais cedo no carregamento ou reduzir parte da carga do navegador do cliente, você pode querer usar uma solução SSR.

A maneira mais fácil de ver se o JavaScript é necessário na página é clicar no cadeado no Chrome e abrir as configurações do site. Você verá uma lista de permissões, sendo uma delas JavaScript, onde você pode permitir ou bloquear. Bloquear JavaScript, recarregar a página e comparar o site com e sem JavaScript deve mostrar se algum elemento está faltando na página ou não. Se algo estiver faltando, reative o JavaScript e siga o mesmo processo de bloqueio que fizemos com o CSS acima para descobrir quais arquivos são críticos para o conteúdo renderizado.

Mover para Rodapé

Para scripts embutidos, considere movê-los para o rodapé. Lembre-se de que o JavaScript bloqueia o analisador, o que significa que está impedindo a leitura do HTML. Mover esses scripts para o rodapé garante que muitos dos dados possam ser processados ​​antes que qualquer bloqueio ocorra. Você tem outras opções para referências de script que provavelmente são melhores, como defer e async.

Adiar/Assíncrono

Defer e Async são atributos que podem ser adicionados a uma tag de script. Normalmente, um script que está sendo baixado bloqueia o analisador durante o download e a execução. Async permitirá que a análise e o download ocorram ao mesmo tempo, mas ainda serão bloqueados durante a execução do script. O adiamento não bloqueia a análise durante o download e só é executado após a conclusão da análise do HTML.

Exemplos de código adiar/assíncrono

Normal:
<script src="https://www.domain.com/file.js"></script>

Assíncrono:
<script src="https://www.domain.com/file.js" async></script>

Adiar:
<script src="https://www.domain.com/file.js" defer></script>

Addy Osmani tem um bom detalhamento de bloqueio, assíncrono, adiamento e pré-carregamento e como isso afeta as prioridades do navegador.

 

Capacidade de resposta

A capacidade de resposta geralmente é medida pelo primeiro atraso de entrada (FID) , que é o tempo desde que um usuário interage com sua página até que ela possa responder. O FID de potencial máximo é o FID de pior caso que seus usuários podem experimentar. Muitas pessoas normalmente medem o Time To Interactive (TTI), que é quanto tempo leva para uma página se tornar totalmente interativa.

Lembra que as coisas que mencionamos anteriormente estavam acontecendo no thread principal? Bem, há apenas um thread principal e o JavaScript compete por esses recursos. Enquanto o thread está bloqueado, ele não pode responder à entrada do usuário, então a página parece lenta. Quando um usuário clica e a página não realiza a ação solicitada prontamente, ele sente esse atraso. Quando isso acontece, seus usuários podem avisá-lo e não de uma maneira agradável.

O que afeta a capacidade de resposta é o JavaScript. Todo o JavaScript carregado para todas as coisas diferentes que ele pode realizar precisa ser executado no mesmo local.

A imagem acima é a aparência do thread principal. Essas marcas vermelhas na guia Desempenho nas Ferramentas de desenvolvimento do Chrome indicam onde pode haver alguns problemas. Normalmente, as tarefas que levam muito tempo para serem executadas no thread principal são as sinalizadas. Cada um deles é onde a página está sobrecarregada com trabalho e não pode responder prontamente às entradas do usuário.

Enquanto uma tarefa está em execução, uma página não pode responder à entrada do usuário. Este é o atraso que se sente. Quanto maior a tarefa, maior o atraso experimentado pelo usuário. As pausas entre as tarefas são as oportunidades que a página tem de alternar para a tarefa de entrada do usuário e responder ao que ele deseja.

Etiquetas de terceiros

Este é outro relatório que você pode encontrar no PageSpeed ​​Insights. Ele mostra o tamanho e por quanto tempo os scripts de terceiros estavam bloqueando o thread principal e impactando a interatividade.

Observe que, especialmente com gerenciadores de tags, algumas coisas podem contar para o gerenciador de tags e não para o script que é o problema. Pode ser parte do script no contêiner contando para um gerenciador de tags e não contado corretamente para o script de terceiros.

Use o tamanho e o tempo de thread principal para determinar do que você pode se livrar. Lembre-se de que a maioria dos scripts de terceiros adiciona algum tipo de funcionalidade, rastreamento ou segmentação, mas raramente são necessários para que uma página funcione corretamente. Use seu critério para determinar se os dados obtidos valem o tempo de carregamento extra para esses scripts.

Fontes comuns de JavaScript Bloat:

• jquery
• Sistemas de teste A/B
• Sistemas de mapa de calor
• Sistemas de monitoramento de usuário real (RUM)
• Sistemas de bate-papo ao vivo

Opções de limpeza:

1. Use menos rastreamento/scripts.  Essa pode ser uma decisão difícil, pois os profissionais de marketing gostam de dados, mas às vezes a quantidade de dados coletados é simplesmente absurda.
2. Consolide sistemas com funcionalidade semelhante , como se você estivesse executando vários sistemas analíticos ou vários sistemas com informações do usuário. Muitos programas têm múltiplas funções e, às vezes, você acaba com scripts que têm a mesma funcionalidade ou funcionalidade semelhante a outro script, quando talvez você possa ficar sem um deles.
3. Segmentação . Por exemplo, alguns sistemas de teste A/B irão armazenar e forçar você a carregar uma lista de todos os testes atualmente no sistema, aumentando o tamanho do download. Muitas vezes você pode segmentar por seção do site e criar versões menores do arquivo.
4. Rastreamento do lado do servidor em vez do lado do cliente.  Existem compensações com o rastreamento dessa maneira que não abordarei aqui, mas você pode encontrar muitos recursos sobre por que usar um em detrimento do outro.
5. Use web workers para mover o processamento para fora do thread principal.  A desvantagem de fazer isso é que o web worker não terá acesso ao DOM. Isso também é bastante avançado e requer desenvolvedores qualificados.
6. Trabalhadores de serviço / Trabalhadores de borda.  Estou animado com o que o futuro reserva com essa tecnologia. Basicamente, permite que o JS seja executado no Edge (ou no nível do CDN) em vez de no navegador do cliente. Portanto, antes de um sistema de teste A/B, pode ser que um arquivo seja baixado e depois processado e executado no navegador do cliente. Como o teste pode sobrescrever partes do DOM e acontecer mais tarde no carregamento, você pode ver flashes visuais à medida que as coisas mudam. Agora, basicamente, você pode pré-processar as alterações que seriam feitas e entregá-las em linha com o HTML que é entregue aos bots e usuários. Algumas plataformas já estão aproveitando isso .
7. Simplesmente atrase a execução do carregamento de um arquivo  se não for necessário imediatamente ou apenas inicie a solicitação de arquivo com base em uma ação como um clique. Por exemplo, um sistema de bate-papo ao vivo provavelmente não é necessário nos primeiros cinco segundos do carregamento da página, portanto, atrase-o. Você também pode solicitar o arquivo depois que alguém passar o mouse ou clicar em um botão para que ele não seja carregado com a página inicial. Ou use uma imagem com um botão de reprodução em vez de incorporar um vídeo do YouTube e carregue apenas os elementos de vídeo do YouTube e reproduza o conteúdo quando um usuário clicar.

Benefícios do JS Frameworks:

Frameworks JavaScript como React, Angular e Vue têm alguns benefícios em relação aos sistemas tradicionais.

• Agitação da árvore : entregando apenas o código usado na página. Quaisquer arquivos ou códigos adicionais desnecessários não são carregados, resultando em arquivos e páginas menores. Ele elimina o código tradicionalmente necessário para todas as outras páginas e possibilidades.
• Divisão de código : Divisão de arquivos em partes menores, para que haja mais oportunidades de interatividade. Por exemplo, digamos que você tenha um arquivo JS de 1 MB que é executado como uma tarefa longa no thread principal e bloqueia a interatividade enquanto é executado. Você pode dividi-lo em blocos de 50 KB para que as tarefas não sejam tão longas e haja mais espaços intermediários em períodos mais curtos em que uma página pode responder à entrada do usuário.

Fontes de tipo de arquivo

Com fontes, você tem muitas das mesmas opções mencionadas anteriormente (por exemplo, inlining ou pré-carregamento de uma fonte necessária). Você encontrará alguns exemplos de código para pré-carregar fontes aqui  se quiser seguir esse caminho. No entanto, com fontes, o que eu recomendaria é usar font-display: swap;, que simplesmente usa uma fonte padrão do sistema até que a fonte personalizada esteja pronta e, em seguida, troca a fonte personalizada. Isso é relativamente fácil de fazer em sua folha de estilo.

@Tipo de letra {
  font-family: 'Tanto faz';
  exibição de fonte: swap;
}

Se você estiver usando fontes do Google, é ainda mais fácil. Tudo o que você precisa fazer é adicionar &display=swap como parâmetro na URL.

<link href="https://fonts.googleapis.com/css?family=Whatever&display=swap" rel="stylesheet">

Imagens de tipo de arquivo

A principal preocupação com as imagens é seu tamanho e peso. Você deseja imagens otimizadas que carregam o tamanho certo para o dispositivo certo e com a qualidade certa.

As imagens são carregadas de forma assíncrona, portanto, não bloqueiam o carregamento da página, mas podem aumentar o peso e o tempo geral da interação.

Outro problema potencial tem a ver com a priorização, onde algumas imagens podem não ser priorizadas corretamente ou priorizadas antes de arquivos críticos como CSS e JS. Não vou entrar em detalhes sobre isso, mas você pode encontrar mais detalhes e algumas informações sobre como solucionar problemas aqui  e aqui . Também pode haver condições em que muitas imagens são carregadas, maximizando recursos como a largura de banda e diminuindo o carregamento geral da página.

Muitas das coisas sobre as quais falamos, como inline e pré-carregamento, podem ser usadas para imagens, mas com as mesmas compensações, como cache ou complexidade. A regra número um é não usar muitas imagens ou imagens grandes acima da dobra em seu tema. Você não precisa mostrar suas imagens de fundo gigantes em dispositivos móveis. As pessoas podem viver sem eles. Se você precisar mostrar as imagens, o que eu recomendo é pré-carregar, e isso é abordado de forma bastante completa neste guia .

Há um ótimo guia sobre otimização de imagem e formatos diferentes em https://images.guide/ .

Sempre faça otimização de imagem de forma escalável. Existem muitas opções para fazer isso em diferentes níveis, como com o CDN, servidor, pelo CMS, com uma API, etc. Aqui estão algumas opções:

CDNs de otimização de imagem:
Akamai Image Manager
imgix
Image Engine
Cloudinary
Uploadcare

APIs de otimização de imagem:
ShortPixel
Fastly Image Optimizer
Kraken.io
TinyPNG
Imagify

GUI:
ImageOptim
Squoosh

Linha de comando:
Imagemin  também possui um módulo npm  se você estiver usando webpack, gulp ou grunt

JPEG:
Guetzli
MozJPEG
PNG:
pngquant
Zopfli

GIF:
Gifsicle
SVGO

WordPress/Drupal

Não tenho nenhuma recomendação em particular. Você encontrará muitas opções para WordPress  e Drupal .

Lazy Load Images

Se alguém lhe disser que precisa “adiar imagens fora da tela”, é disso que você precisa. Basicamente, está atrasando o carregamento de imagens que não estão acima da dobra porque ainda não são necessárias. Assim que o usuário começar a rolar, as imagens serão carregadas.

Eu diria que você deseja uma biblioteca que use IntersectionObserver, mas provavelmente tenha um polyfill devido ao suporte do navegador. A biblioteca mais popular para isso é lazysizes , mas você encontrará muitas opções para sua configuração.

A partir do Chrome 76, o carregamento lento foi introduzido no navegador. Espero que mais navegadores façam o mesmo em breve, mas, por enquanto, podemos usar esse método para o Chrome com um polyfill para outros navegadores. Você pode encontrar mais informações aqui . O WordPress adicionou carregamento lento por padrão na versão 5.4 .

Imagens responsivas/redimensionadas

Trata-se de fornecer a imagem certa para a tela certa. Carregar uma imagem grande e reduzi-la apenas desperdiça tempo e recursos. Novamente, existem muitas soluções automatizadas para isso. Por exemplo, muitos CDNs irão lidar com isso, e também há coisas como o pacote sharp npm , a ferramenta ImageMagick CLI ou vários plugins/módulos para sistemas diferentes.

Mudando Formatos de Imagem

Diferentes formatos como webp podem ser melhores, mas são problemáticos devido ao suporte do navegador. Você precisa fazer muita detecção e troca ou usar um serviço que faça isso por você. Existem muitos guias , mas não é algo que eu recomendaria para a maioria das pessoas, a menos que você encontre uma maneira fácil e automatizada.

Tamanho/peso da página

Este é o tamanho de todos os recursos combinados. Páginas menores são mais rápidas. Já falamos sobre muitas das melhorias, como minificação, compactação e simplesmente livrar-se de tudo o que não é usado. Quanto menos uma página tiver que carregar inicialmente, mais rápido a página será exibida.

O objetivo deve ser uma quantidade mínima de dados para que o conteúdo acima da dobra seja carregado o mais rápido possível. Você pode carregar o restante das informações necessárias na página depois, mantendo tudo o mais pequeno possível. Os problemas geralmente vêm de código não utilizado, imagens e inchaço geral do site relacionado a funcionalidades ou ferramentas. A razão pela qual estou dando a esta sua própria seção é que você deve levar em consideração a quantidade geral de dados que sua página está usando.

Confira Quanto custa meu site  para ver o custo aproximado para os usuários que carregam sua página.

Outras oportunidades de desempenho na Web

Há muitas opções de coisas que você pode fazer para melhorar a velocidade da sua página. Vou cobrir alguns mais importantes, mas há muito mais oportunidades por aí porque a velocidade da página é um tópico muito complexo.

Cache

Um cache é simplesmente uma cópia armazenada de um arquivo. Os arquivos em cache podem ser reutilizados na próxima página sem a necessidade de baixá-los novamente.

Cache do servidor

É daí que vêm os arquivos quando um navegador os solicita. Idealmente, você deseja atingir o cache mais próximo do usuário. O que quero dizer com isso é que os caches podem ser armazenados em muitos níveis diferentes, com diferentes TTLs definidos para cada um que faz com que o cache expire. Há um equilíbrio entre o armazenamento em cache por períodos mais longos e a atualização rápida do conteúdo com as alterações. Não é tão simples assim, pois você pode limpar o cache através de diferentes camadas quando uma atualização é feita, que é a maneira ideal de fazer isso junto com um sistema de aquecimento de cache. Os sistemas de aquecimento de cache enviam um bot para reconstruir o cache em vez de esperar que um usuário solicite os arquivos, o que significa que um usuário nunca precisa esperar enquanto o cache inicial é criado.

Uma verificação geralmente é algo como: Cache CDN > Cache do servidor (como Varnish) > Origin (tem que construir a página em tempo real). Geralmente, um cache de nível superior como o CDN será mais rápido, portanto, você deseja que a maioria de seus acessos esteja nesse nível.

Por exemplo, em um dos meus sites na Cloudflare mostrado abaixo, tenho uma taxa de acerto de cache de pouco mais de 50% para o nível CDN. Infelizmente, isso significa que muitas solicitações não são atendidas pelo CDN e precisam voltar ao cache no nível do servidor. Ou, se não houver uma versão atual em cache, será necessário criar a página em tempo real, que usa muitos recursos do banco de dados e será mais lenta para o usuário.

Cache do navegador

Mesmo se você tiver um site grande que teste mal a velocidade da página, pode haver uma diferença considerável entre o primeiro e o segundo carregamento de uma página ou a navegação entre as páginas. Muito do que falamos até agora foi focado em tornar o carregamento inicial mais rápido. Isso é o que a maioria das ferramentas de teste vê e é a primeira impressão do usuário sobre seu site. Quando um usuário visita uma página, um navegador pode armazenar em cache muitos dos arquivos localmente no computador da pessoa, que podem ser reutilizados para exibições de página subsequentes.

Por exemplo, observe a diferença entre a primeira e a segunda carga para Ahrefs. A maioria dos arquivos que tiveram que ser baixados no primeiro carregamento são armazenados em cache no lado do cliente (navegador), o que significa que o segundo carregamento pode apenas reutilizar os já baixados para criar a página. Cortar o tempo de conexão e downloads significa que a página carrega significativamente mais rápido. Nesse caso, a primeira pintura ocorre aproximadamente duas vezes mais rápido na segunda carga.

1ª carga:

2ª carga:

Você verá problemas de cache sinalizados em ferramentas como o Lighthouse como “servir ativos estáticos com uma política de cache eficiente”. Definir o período de tempo para o cache varia de acordo com o sistema, mas geralmente o que você precisa fazer é usar um cabeçalho de resposta HTTP Cache-Control. A idade máxima é o tempo que você deseja armazenar em segundos e pode ser definido como:Cache-Control: max-age=31536000

Varvy tem um guia para configurar controles de cache em diferentes servidores  que vale a pena ler.

Defina um orçamento de desempenho (talvez)

Um orçamento de desempenho é um conjunto de limites auto-impostos em métricas que afetam o desempenho. Podem ser coisas como tamanho, o número de um determinado tipo de arquivo ou algumas das métricas de velocidade das quais falamos. Definir um orçamento pode ajudar a iniciar a conversa. Saiba mais aqui .

Carregamento Adaptável

O carregamento adaptável ajusta o que é carregado e quando para tornar os sites mais progressivos em como eles são carregados. Os recursos e funcionalidades prioritários são carregados primeiro e o restante é carregado posteriormente com base em itens como CPU, memória ou velocidade da rede. Portanto, ter menos recursos disponíveis significa que uma versão simplificada do site pode ser entregue, mas as pessoas com mais recursos disponíveis terão toda a experiência.

Uma parte disso é a API de informações de rede, que fornece informações sobre a conexão do usuário. Você pode alterar suas imagens/conteúdo ou fazer coisas como desligar vídeos com base nas informações de rede da solicitação recebida. Muitos dos CDNs de imagem fazem isso usando a API de informações de rede .

Use outras dicas de recursos

Pré-busca

Prefetch é uma dica de recurso que obtém um arquivo antes de ser necessário. Isso pode ser para páginas inteiras, scripts ou arquivos CSS. Uma das melhores maneiras de usar isso é com Guess.js , que usa pré-busca preditiva. Guess se conecta ao seu Analytics e busca a próxima página mais provável com base no comportamento atual do usuário.

Pré-carregar

Já falamos um pouco sobre o pré-carregamento, mas esse é um caso de uso um pouco diferente. Você pode pré-carregar recursos com base em coisas como um usuário passando o mouse sobre um link  ou links na janela de visualização atual. Embora isso possa ser um tanto intensivo em recursos, garante que a próxima página carregada apareça muito mais rapidamente.

AMP

O AMP pré-carrega na SERP, então parte do site já está carregada antes de clicar. O AMP tem a vantagem de fazer o carregamento visual da página antes mesmo de clicar. O AMP parece mais rápido do que as páginas da Web normais quando provenientes dos resultados da pesquisa porque a parte visível da página já está carregada.

Existem muitos outros aprimoramentos de desempenho e limitações de tamanho de arquivo no AMP que valem a pena considerar. Ainda assim, é mais um sistema para manter e tem algumas outras compensações que você provavelmente deseja examinar antes de mergulhar.

Dados de laboratório versus dados de campo

Dados de laboratório : As características são um ambiente controlado, processo repetível e controle de configurações. O PageSpeed ​​Insights é um ótimo exemplo. O teste é executado no mesmo ambiente com as mesmas configurações e os resultados serão aproximadamente os mesmos em cada execução.

Dados de campo : Real User Monitoring (RUM) é como os usuários experimentam a página. Ele leva em consideração tudo como cache, dispositivos, redes, etc., mas é limitado em métricas e capacidade de depuração.

Ferramentas para medir a velocidade da página

Ferramentas do Google

• TestMySite  – Contém um cartão de pontuação de velocidade onde você pode avaliar sua velocidade em relação aos concorrentes, possui uma calculadora de impacto para que você possa estimar o impacto que a velocidade está causando em seus negócios e permite criar um relatório que inclui essas e algumas recomendações sobre pontos a serem focados sobre.
• Lighthouse  (no Chrome Dev Tools) – Permite testar o desempenho de páginas e aplicativos.
• PageSpeed ​​Insights  – Executa o Lighthouse  e fornece recomendações. A execução do Lighthouse em seu navegador é afetada por muitas coisas, como seu computador, sua rede, extensões em seu navegador etc. .
• Chrome Dev Tools  – Muitos recursos úteis para ver o que e como uma página está carregando, como as guias Rede e Desempenho.
• Relatório de experiência do usuário do Chrome (CrUX)  – Um conjunto de dados público de dados reais da experiência do usuário para aqueles que optaram por compartilhar no Chrome, abrangendo milhões de sites. Dados de campo (dados de usuários reais) para velocidade da página.
• Web.dev  – Outra ferramenta de teste do Google apoiada pelo Lighthouse. Ele também possui uma seção para aprender mais sobre a velocidade da página.

Outras ferramentas de velocidade populares

• WebPageTest
• Sitespeed.io
• SpeedCurve
• Calibre
• Rigor
• nova relíquia
• Bumerangue
• Velocidade do Lote
• GTmetrix
• Pingdom
• SpeedMonitor.io

Auditoria do Local > Desempenho

A ferramenta Site Audit da Ahrefs  também contém algumas informações sobre a velocidade da página. Há um relatório para TTFB e para Load Time, que é quanto tempo levamos para baixar a página.

O que eu pessoalmente costumo usar:

1. Pagespeed Insights  – verificação pontual de páginas individuais. Eu também gosto da API deles. Ele permite 25 mil testes por dia sem nenhum custo e retorna com muitas métricas, incluindo dados CrUX em nível de página. Direi que não presto muita atenção à pontuação geral, mas sei que muitas pessoas se concentram nessa métrica. Como vimos, a velocidade é complexa e você pode estar melhorando em algumas métricas, mas não ajudando na sua pontuação apenas por causa de como ela é ponderada .
2. WebPageTest  – a função de bloqueio, tiras de filme, vídeo, cascata e requestmap. Além disso, sua API para teste de bloqueio em escala (com relatórios de farol também).
3. GTmetrix  – o relatório de solicitações encadeadas.
4. CrUX  – pesquisa de região, histogramas, comparação de concorrentes.
5. Web.dev  – a documentação é ótima.

Quais dados o Google está usando para velocidade de página?

De acordo com o analista de tendências para webmasters do Google, John Mueller, neste vídeo , o Google usa a velocidade teórica de uma página (usando dados de laboratório) e dados de campo reais de usuários que tentaram usar essas páginas. Ele diz que isso é semelhante aos dados do relatório de experiência do usuário do Chrome.

A realidade é que não houve nenhuma confirmação pública da fonte dos dados que eles usam. Embora John não diga que eles usam dados do PageSpeed ​​Insights e CrUX, os dados deles provavelmente representam os dados usados ​​pelo Google. Meu melhor palpite (e isso é puramente especulativo) é que eles usam medidas tomadas durante o processo de renderização como dados de laboratório (potencialmente por farol, mas talvez não) e provavelmente têm um recurso interno semelhante ao CrUX que estão usando para o campo dados.

A maneira mais fácil de estimar o impacto é fazer uma cópia estática de uma página. Copie o código para seu servidor e teste a página para obter uma métrica de linha de base. Faça alterações na página e teste novamente, e você deve obter o impacto aproximado das alterações; portanto, ao fazê-las em seu site ativo, você saberá o impacto aproximado