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

Como melhorar a velocidade da página do início ao fim (Guia Avançado)
cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


Existem muitas ferramentas para testar a velocidade da página e várias métricas diferentes para segmentar. Mas você entende como essas otimizações funcionam ou se elas realmente tornarão seu site mais rápido?

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

Dito isso, se você não é técnico e deseja instalar um plug-in / módulo para acelerar seu site, veja alguns exemplos que devem ajudar:

WordPress:

Drupal

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

A velocidade da página é o tempo necessário para o carregamento de uma página da web. É difícil atribuir um número único à velocidade da página, porque muitas métricas capturam elementos da página carregados de maneiras diferentes, para diferentes propósitos e com diferentes condições de teste.

Contents

Por que você deve se preocupar com a velocidade da página

Houve recentemente um foco renovado na velocidade da página do Google, 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 os motivos pelos quais você deve se preocupar:

  • Impacta a experiência do usuário. Você deseja que os visitantes tenham uma experiência rápida e suave. 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 acionada, 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 vários estudos mostrando que, se você aumentar a velocidade da página, verá aumentos em tráfego orgânico, taxa de cliques para visitar em anúncios, mais visitantes em geral e muitos outros benefícios. WPO O Estatísticas possui muitos exemplos de estudos sobre melhorias na velocidade da página.

No entanto, vou advertir que muitos desses estudos podem ser um pouco enganadores. A menos que você tenha sido extremamente lento antes, o Google diz que melhorar a velocidade da página não deve afetar seus rankings.

Então, por que você vê mais visitantes?

A resposta é que a tag de análise provavelmente foi acionada mais cedo do que antes e conseguiu gravar mais pessoas antes de sair de uma página.

Quão rápido minha página deve carregar?

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

Essa recomendação também é provavelmente baseada na métrica do Índice de Velocidade, sobre a qual falaremos mais adiante, mas essa é apenas a 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. Geralmente, as recomendações dos representantes do Google são genéricas como “tornar os sites mais 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, analisaremos principalmente os gráficos Waterfall para ver quais recursos estão carregando. Você também pode ver isso no seu navegador usando “clique com o botão direito”> Inspecionar> e exibindo a guia Rede ao carregar uma página.

Nota.

Vou usar https://www.webpagetest.org/ para muitas imagens e vincular os testes e listar as configurações, quando aplicável.

Estabelecendo conexões

O verde, laranja e roxo abaixo representam o tempo necessário para estabelecer uma conexão com o site. Vou ver cada cor abaixo e o que ela representa.

1 estabelecendo conexões 3

Gráfico em cascata para a página de tema TwentyTwenty WordPress em WebPageTest.org (veja aqui). Localização: Dulles, VA. Equipamento: Moto G4. Navegador: Chrome. Velocidade: 3G

DNS (Verde)

Sistema de nomes de domínio (DNS) é considerada a lista telefônica da web. Você atribui ao navegador um nome de site e ele verifica com um DNS servidor para obter um IP endereço (uma etiqueta de localização) informando onde o site está hospedado. É como armazenar um contato no seu telefone, assim você só precisa saber o nome e não o número de telefone.

Na maioria das vezes, o 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, nem todos DNS provedores são criados iguais. Se cada milissegundo é importante para você, considere usar um DNS fornecedor. 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 completamente precisa, pois DNS pode ser armazenado em cache (armazenado temporariamente) no navegador quando você já visitou um site. A quantidade de tempo em cache é chamada de TTL (Tempo de Viver). Enquanto o cache ainda estiver ativo, o navegador não precisará se conectar ao DNS servidor para saber para onde acessar o site.

Conectar (laranja)

É aqui que o navegador está estabelecendo uma conexão com o servidor de hospedagem. Protocolo de Controle de Transmissão / Protocolo da Internet (TCP/IP) é complicado, mas pense em como você começa a trabalhar. Provavelmente não é uma linha reta; você precisa fazer curvas e haverá áreas com maior tráfego. Você pode até redirecionar ou fazer algumas curvas erradas. É assim que isso funciona; está encaminhando 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, a perda de pacotes pode ocorrer e precisará ser reenviada. É como perder a sua vez 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 levar, até onde deve ir, quanto outro tráfego há na rede são semelhantes a quantas voltas você precisa fazer, a que distância do trabalho e a quantos outros carros estão na estrada Isso pode atrasá-lo. Também há capacidade de conexão e limitação de taxa no servidor, que seria semelhante a um túnel que só permite tantos carros por vez.

Leia Também  5 Horas de SEO Recapitular

Muitos desses problemas são resolvidos, diminuindo a distância para o servidor e usando um roteamento mais inteligente – o que muitas CDNs podem fazer. Com uma rede de servidores em todo o mundo, os visitantes geralmente podem se conectar a um próximo. Alguns CDN os provedores 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 torno de um engarrafamento.

Camada de soquetes seguros (SSL) (Roxa)

Para sites que estabelecem uma conexão segura (HTTPS), é aqui que o navegador e o servidor estão concordando com a TLS Versão do protocolo (Transport Layer Security), o ciphersuite (nível de segurança) e a verificação do certificado (para garantir que o site seja o que diz ser).

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 os navegadores não permitirem que você use HTTP/ 2 (H2) sem HTTPS. H2 possui algumas vantagens, como conexões persistentes, portanto, não é necessário continuar abrindo uma nova conexão para arquivos no mesmo servidor. Os cabeçalhos nessas 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, sites que usam HTTPS e H2 será mais rápido do que sites em HTTP.

Geralmente, os ganhos mais significativos que você obtém aqui vêm da atualização do seu protocolo (TLS 1.3 é mais rápido que TLS 1.2, por exemplo) e implementação HTTP Segurança estrita de transporte (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 gasto seria eliminado usando HSTS.

2 soquetes seguros camada 3

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

Importante: Dispositivo, local e questão de rede

Considere isso, conectando-se a um site em um smartphone de nível médio com um lento 3G a conexão leva ~ 2 segundos. No mesmo telefone com um LTE conexão, é reduzido para ~ 0,41 segundos. Em um computador de mesa com velocidade normal, leva menos de 0,1 segundos para fazer essa conexão.

Lembre-se disso se você observar tempos de conexão mais longos, pois pode ser devido à largura de banda limitada ou ao poder de processamento do dispositivo de teste. Esses fatores – juntamente com o cache – são importantes. Eles podem ajudá-lo a explicar a alguém que pode obter seu smartphone mais recente, conectado ao Wi-Fi, com todos os arquivos necessários para carregar a página já armazenada em cache no dispositivo (falaremos sobre isso em outra seção) que a maneira como eles estão enfrentando o site está em condições ideais e não como a maioria das pessoas o experimentará.

Download e processamento HTML

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

3 download de html 3

Se houver um atraso para TTFB, pode ser devido a consultas ao banco de dados, recursos do servidor, aguardando uma renderização no servidor (SSR) para concluir 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 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 encadeamento principal existe e lida com muitas tarefas diferentes. Abordaremos isso um pouco mais tarde.

Se você vir uma lacuna entre HTML e na próxima solicitação, a causa mais provável é que o CPU está ocupado processando o HTML para construir o DOM. Já que é o CPU, isso depende novamente do dispositivo que está sendo usado, para que você possa testar com um dispositivo mais poderoso para verificar 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ço em branco do código e compactação para reduzir o tamanho dos arquivos. O objetivo é diminuir o download do arquivo para que essa parte da carga seja mais rápida. No entanto, não há apenas uma maneira de realizar minificação e compactação. Em muitos casos, isso é tratado pelo CDN ou o servidor (Apache ou Nginx são servidores comuns) ou por um plugin / módulo / pacote. Você pode encontrar mais informações sobre como implementar a compactação aqui e a minificação aqui.

Manipulação de conexões adicionais

Quando o HTML foi baixado, as referências a outros arquivos e outros servidores serão processadas e novas conexões serão iniciadas. Normalmente, é onde outros arquivos como JavaScript, CSS, Imagens e Fontes são adicionadas à 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ções abaixo para Forbes.com. Cada ponto é uma solicitação de arquivo individual e cada linha é onde um arquivo faz referência a outro arquivo que precisa ser baixado. No geral, são 363 solicitações 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, haveria um benefício em usar vários domínios (um processo chamado compartilhamento de domínio) devido aos limites de solicitação de conexão definidos pelo navegador.

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

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

4 mesmo servidor 3

Se esse arquivo estivesse hospedado em ahrefs.com, nem seria necessário fazer a conexão. Está sendo adiado pelo tempo para fazer o DNS conexão, para conectar e negociar o handshake de segurança. Sem os bastidores extras para pular, teríamos o arquivo mais cedo, o que significa que a página seria carregada ainda mais rápido.

No entanto, enquanto a hospedagem automática de muitos arquivos, como fontes, pode levar a ganhos, pode haver outras desvantagens, como cache (armazenamento de uma cópia de um arquivo), em que os navegadores às vezes podem ter recursos comuns 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 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 você usar um servidor diferente, faça a pré-conexão com 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 inicia antes do HTML é até o processamento finalizado.
5 pré-conexão dns pré-busca 3

Exemplo de código:

Também existe uma pré-busca de DNS, se você quiser lidar com essa parte da conexão mais cedo. O verde (DNS) se conectaria mais cedo, mas o restante da conexão acontecerá mais tarde. A pré-busca de DNS tem melhor suporte do que a pré-conexão, 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 nesse servidor precisa ser carregado com antecedência para que a página funcione. No entanto, como a pré-conexão requer mais trabalho para roteamento e segurança (laranja e roxo), também será um pouco mais intensivo em recursos desde o início.

Leia Também  Espectador para Parceiro: Transforme Seus Clientes em Aliados de SEO - Best of Whiteboard Friday

Exemplo de código:

Como os navegadores processam 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 ativá-las, 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 criar a página. Esse processo geralmente é chamado de caminho de renderização crítica e é assim:

  1. HTML é processado no DOM árvore que mencionamos anteriormente
  2. CSS é analisado no CSS Modelo de Objeto (CSSOM), que informa ao navegador como tudo é estilizado, acolchoado, colorido, dimensionado etc.
  3. o CSSOM + DOM juntos, faça o que é chamado de Árvore de Renderização.imagem colada 0 61
  4. O layout acontece, que é o processamento do local em que cada elemento estará na janela de exibição do navegador, com base no que está na Árvore de renderização.imagem colada 0 58
  5. Os pixels são pintados na tela e, em vez de uma tela branca, você vê cores, formas, texto e imagens.

Nota.

Um fato divertido revelado por Martin Splitt O Googlebot economiza tempo e recursos ao não pintar os pixels de uma página. Eles têm as informações necessárias após o layout.

O objetivo deve ser obter os elementos necessários o mais cedo possível para criar a visualização inicial o mais rápido possível. O tempo de carregamento visível é a visão percebida das pessoas sobre a velocidade de uma página, ou seja, em quanto tempo o conteúdo aparece na tela para elas. O que mais afeta isso é como os recursos são carregados. Geralmente é de responsabilidade do CMS ou JavaScript Framework para ajudar o navegador a priorizar quando / o que / como os recursos serão carregados em que ordem para tornar o site 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 sobre a simplificação do processo de pintura.

Métricas de carga visual:

  • First Paint (FP) – o navegador renderiza qualquer coisa pela primeira vez.
  • Primeira pintura com conteúdo (FCP) – o navegador renderiza algo do DOM (Modelo de objeto de documento), que pode ser texto, imagem, etc.
  • Primeira pintura significativa (FMP) – elementos mais importantes visualmente carregados.
  • Maior tinta com conteúdo (LCP) – o maior elemento acima da dobra carregado.
  • Visualmente Completo – 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.
  • Mudança cumulativa de layout (CLS) – Mede a quantidade de elementos que se movem na janela de exibição durante o carregamento ou a estabilidade do layout. Há um bom guia para as causas de CLS aqui.

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

Na seção Resumo do WebPageTest, se você tiver ativado a gravação, deverá ter uma coluna de vídeo na tabela principal com “Exibição de tira de filme”. Nesta visualização, a linha vermelha na parte superior com os instantâneos visuais está no mesmo ponto da linha vermelha na parte inferior da cachoeira.

Cascata de carga visual 6 3

Movendo a linha vermelha para diferentes pontos da carga visual, você poderá ver o que acabou de ser carregado na cascata que pode ter permitido que diferentes elementos sejam exibidos visualmente. Isso pode ajudar a determinar quais arquivos talvez você precise priorizar.

Por exemplo, se você vir que a maior parte da sua página está carregada, exceto o texto, mas logo após o carregamento de uma fonte e o texto aparecer, é 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, basta olhar as capturas de tela geradas.

Na parte inferior deste gráfico, há informações adicionais, como CPU Utilização, largura de banda, atividade no segmento 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 exista muito download, o que mantém a largura de banda no ponto mais alto. Ou talvez haja um script usando todos os CPU para um determinado dispositivo, o que pode causar atrasos.

imagem colada 0 65

Tipo de arquivo CSS

Onde a velocidade da página fica complicada é que, em muitos casos, não existe uma maneira correta de fazer as coisas. A maioria dos métodos tem vantagens e algumas são mais complexas de implementar e manter. Você precisa decidir o que é mais fácil, rápido e melhor para você em suas circunstâncias.

Olhando para CSS arquivos, eles são bloqueados por padrão, o que significa que precisam ser baixados e processados ​​antes que uma página exiba conteúdo para o usuário. Se você armazenar em cache (armazenar uma cópia do arquivo, abordada mais adiante neste artigo), esse arquivo poderá ser reutilizado para carregamentos de páginas subsequentes. Isso significa que não será necessário fazer o download novamente e as próximas visualizações devem ser 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 apenas exibe uma página e não de alguém que visita várias páginas ou volta frequentemente ao seu site . Seu objetivo deve ser otimizar a primeira visualização e as subsequentes para os usuários.

Carregando CSS 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 é que você deseja CSS para não bloquear 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 será aplicado a todos os tipos. Ele está enganando o navegador, abusando de como ele lida com o carregamento de atributos específicos do elemento do link. O que ele fará é carregar o CSS sem bloquear a renderização (porque, neste caso, informamos ao navegador que esta folha de estilo é para impressão e não realmente para esta versão da página) e, em seguida, aplica-se a todos os tipos de mídia (itens que não são impressos) após o carregamento.

Por exemplo, isto:

Torna-se isso:

Você pode usar isso com todos os seus CSS referências. A desvantagem é que os usuários podem experimentar algum flash / re-estilização, pois alguns elementos da página podem ser pintados antes do CSS é aplicado. Então, quando o CSS aplicado, a tela pode mudar onde e como as coisas são exibidas.

Na linha

O Inline utiliza o código necessário para renderizar o conteúdo acima da dobra e o entrega com o HTML resposta em vez de um arquivo separado. Normalmente, essa é 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 do CSS e JS arquivos e colocá-lo diretamente no HTML. A inicial HTML 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.

imagem colada 0 59

O inlining provavelmente proporcionará a renderização mais rápida no carregamento inicial da página, mas a troca tradicionalmente ocorre com o cache. O código carregado no HTML não pôde ser reutilizado a partir 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ê incluísse código em todas as páginas, isso também significava que as páginas subsequentes também teriam código extra. Isso é avançado e envolve o uso de profissionais de serviço, mas você pode ter inlining e cache. Combinado com fazer o resto do CSS assíncrono como mencionamos acima, esse é praticamente um estado ideal.

Lembre-se de que você pode reduzir inline CSS código. Como mencionado no HTML Na seção acima, isso remove alguns espaçamentos desnecessários e caracteres extras para tornar o código menor e mais rápido para fazer o download.

Leia Também  O que há de novo no SEMrush [January 2020]

Você provavelmente não deseja incorporar todo o conteúdo de todos os arquivos. Seja atencioso e inline apenas com conteúdo crítico. Você pode tecnicamente alinhar tudo CSS e JS e até fontes e imagens, mas você vai acabar com um gigante HTML faça o download onde grande parte do código não é usada. Isso realmente torna seu site mais lento. Se você tiver alguns arquivos menores de apenas alguns KB e deseja alinhar tudo isso para eles, provavelmente é bom fazê-lo.

Crítica em linha CSS em escala:

Você deseja um sistema automatizado em vez de fazer isso para todas as páginas. Pode fazer sentido alinhar apenas o CSS para a página inicial dos temas do WordPress, pois normalmente possui uma folha de estilo diferente das outras páginas. Geralmente, haverá algum plug-in / módulo / pacote ou uma versão de Crítico ou Crítico CSS. Esses pacotes existem para qualquer executor de tarefas ou pacote que você possa usar como Grunt, Gulp, Webpack ou Framework como React, Angular, Vue, e você pode até encontrar tutoriais específicos para WordPress ou Drupal ou até páginas codificadas à mão. Eles vão enviar um navegador sem cabeçalho para a página para determinar o que CSS é realmente crítico para o carregamento da página em tamanhos diferentes e pode fornecer o código ou dividi-lo em elementos críticos e não críticos, para que você possa carregá-los adequadamente. Alguns exemplos:

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

Gole:
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-critical-css

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

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br

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://joe-watkins.io/javascript/inline-critical-css-with-wordpress/
https://wordpress.org/plugins/wp-criticalcss/

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

Pré-carregamento

Se você não vai alinhar as críticas CSS, a próxima melhor opção é 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. O pré-carregamento define a prioridade do navegador para os recursos pré-carregados como altos e os carrega de forma assíncrona, para que eles não bloqueiem a renderização. Também funciona entre domínios.

O navegador atribui prioridade a cada solicitação de um arquivo. A idéia é obter os arquivos necessários para exibir o conteúdo acima da dobra mais cedo (com prioridade mais alta) e adiar os que não são necessários até mais tarde no processo. Você pode ver a prioridade dada aos arquivos na guia Rede, nas Ferramentas de desenvolvimento do Chrome. Apenas clique com o botão direito do mouse na barra, selecione Prioridade e adicione-a como uma coluna.

7 prioridade de pré-carregamento 3

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 já teria bloqueado a renderização, esse não será mais o caso.

Combinado com o que mencionamos acima para fazer CSS de forma assíncrona, o pré-carregamento apenas adiciona outra linha destinada a obter o arquivo mais rápido, definindo a prioridade do navegador acima do normal. Isso também funcionará para navegadores nos quais o pré-carregamento não é suportado.

Exemplos de código:


Escolhendo quais arquivos pré-carregar

Normalmente, você terá o arquivo de tema principal que contém muitas das CSS para o site. Os desenvolvedores costumam nomear esse nome após o tema, ou chamá-lo de “estilo” ou, às vezes, o nome do próprio site. Se você tiver problemas para identificar esse arquivo ou acredita que outros arquivos também precisam ser pré-carregados, a maneira mais fácil de verificar é usando 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 do mouse neles para adicioná-los à lista de bloqueios. Quando você recarrega uma página, se a página ainda parece normal, provavelmente você não bloqueou um arquivo necessário para o conteúdo acima da dobra. Quando você obtém uma dessas que quebra 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.
URL de solicitação de 8 blocos 3

Coisas a saber sobre pré-carregamento
  1. Você precisa ter uma fonte cruzada de fontes ou obter um carregamento duplo do arquivo.
  2. Você ainda precisa das chamadas de arquivo normais para JS + CSS, então não os exclua.
  3. Você pode pré-carregar uma fonte, mesmo que ela seja chamada em outro arquivo, como um CSS Arquivo.
  4. Cuidado com o quanto você pré-carrega. Você pode encontrar problemas ao tentar pré-carregar muitos arquivos.

Envio do servidor

Isso fazia parte do HTTP/ 2 (H2) especificação. Ele permite que um servidor entregue um arquivo sem que 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 recomendo isso, mas se você é um ótimo desenvolvedor ou tem acesso a um, pode tentar. Ele solicita arquivos do servidor na mesma conexão que a solicitação de página. O envio do servidor pode carregar ativos duas vezes. Existe uma solução alternativa usando cookies e verificando se você já enviou recursos para os 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 obter ganhos significativos sobre o pré-carregamento, porque os navegadores verificam o cache da página (onde está o pré-carregamento) antes do cache de envio.

Tipo de arquivo JavaScript

O JavaScript também pode ser complexo, com muitas opções e muitas considerações. Às vezes, é usado para fornecer funcionalidade, às vezes, para atrair o conteúdo principal e, às vezes, até para fazer alterações no CSS. Além disso, determinado código pode precisar de outro código para funcionar corretamente. These are known as dependencies, and changing how JavaScript is loaded may end up breaking some functionality of the page.

If JavaScript plays a critical role in content or the styling of the page, or if it’s the core system—as is the case with many JavaScript frameworks—then many of the same rules as CSS apply as far as inlining and preloading. However, you also have the option of Server Side Rendering (SSR) This processes the code and renders a snapshot. For instance, if JavaScript is used to populate items on the page or for the menu, you may want this information earlier in the load or reduce some of the burden of the client’s browser, you may want to use an SSR solution.

The easiest way to see if JavaScript is needed on the page is to click the padlock in Chrome and open up Site settings. You’ll see a list of Permissions with one being JavaScript where you can either Allow it or Block it. Blocking JavaScript, reloading the page, and comparing the site with and without JavaScript should show you if any elements are missing from the page or not. If something is missing, re-enable JavaScript and go through the same blocking process as we went through with CSS above to find out which files are critical to the rendered content.

Move to Footer

For inline scripts, you may consider moving them to the footer. Remember that JavaScript is parser blocking, which means it’s blocking the HTML from being read. Moving these scripts to the footer ensures that much of the data can be processed before any blocking occurs. You have other options for script references that are probably better, such as defer and async.

Defer/Async

Defer and Async are attributes that can be added to a script tag. Usually, a script being downloaded blocks the parser while downloading and executing. Async will let the parsing and download occur at the same time but still blocks during script execution. Defer does not block parsing during download and only executes after the HTML has finished parsing.

Defer/Async code samples

Normal:

Async:

Defer:

Addy Osmani has a nice breakdown of blocking, async, defer, and preload and how it impacts browser priorities.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *