O objetivo desta postagem é examinar como os desenvolvedores de front-end criam páginas de destino rápidas, conforme julgado por Core Web Vitals.
Essas métricas de desempenho de página da web são um novo sinal de classificação para a Pesquisa Google e são uma preocupação para profissionais de marketing digital e SEO. Desde que o Google os anunciou em maio de 2000, os proprietários de negócios pediram aos desenvolvedores de front-end que corrigissem páginas lentas e criassem mais rápidas.
Agora que o Core Web Vitals começou a ser implantado, procurei os melhores padrões de desempenho de front-end.
O que são Core Web Vitals?
O tópico Core Web Vitals inclui três métricas de desempenho de página da web centradas no usuário derivadas de dados reais do usuário do Chrome (CrUX). As pontuações são agregadas ao 75º percentil ao longo de um período contínuo de 28 dias. As três métricas são:
Largest Contentful Paint (LCP): o tempo que leva para um site exibir o maior elemento na tela. Deve ser visto pelo usuário em menos de 2,5 segundos First Input Delay (FID): mede o tempo que uma página da web leva para responder à entrada do usuário, que deve estar dentro de 100 milissegundos Mudança Cumulativa de Layout (CLS): este é o inesperado mudança de elementos e layout da página da web conforme a página carrega, portanto, é melhor evitar mudar o layout da página durante o carregamento
É fundamental medir suas páginas em relação aos usuários com conexões e dispositivos mais lentos.
Então, eu esgoto minha conexão para 3G rápido e desacelero minha CPU em 6x. Só então poderei detectar problemas relatados pelo Search Console do Google.
Melhorando sua pontuação do Core Web Vitals
O segredo para corrigir problemas de velocidade de página é fazer engenharia reversa de páginas que já têm Vitais. Primeiro, eu precisava de um tipo de página que fosse comum à maioria dos sites, portanto, para os fins deste artigo, escolhi medir a página de preços onipresente porque eles são visualmente semelhantes em todos os sites e geralmente incluem uma frase de chamariz proeminente.
Em seguida, testei as 114 páginas para celular com Lighthouse e as comparei com Core Web Vitals. Isso me deixou com 25 páginas de destino rápidas para analisar.
As tecnologias nesses sites iam de Next.js a WordPress a Ruby on Rails, e algumas até usavam jQuery. Não importa qual pilha você (é forçado a) usar, sempre há uma maneira de melhorar suas pontuações vitais do Core Web.
Como esses padrões são submetidos à engenharia reversa de páginas existentes usando dados da experiência do usuário do Google Chrome Relatório (CrUX), tenho certeza de que se você segui-los, você construirá uma página da web rápida ou até mesmo consertará uma página lenta.
Para investigar esses padrões por conta própria, recomendo carregar a página, então visualizando o código-fonte.
Mantenha os tempos de back-end abaixo de 600ms
Os 10 sites mais rápidos tiveram respostas do servidor variando de 75ms a 380ms com uma mediana de 110ms. O takeaway? O 75º percentil do campo provavelmente precisa ser consistentemente inferior a 600 ms.
Calcule um orçamento de desempenho
Antes de examinar o código, recomendo fazer um inventário dos arquivos solicitados e dividi-los por tipo de conteúdo. Em seguida, compare sua página com a de uma página rápida. Isso é chamado de orçamento de desempenho.
Eu criei meu orçamento dividindo cada tipo de arquivo que carrega antes da pintura com maior conteúdo (LCP). Por exemplo, Shopify carrega mais de 100 arquivos, mas constrói a página de modo que carregue 17 arquivos antes da maior pintura com conteúdo.
Antes do LCP, as páginas rápidas geralmente carregam:
Menos de 35 arquivos no total Quatro ou menos scripts de terceiros Nenhum arquivo de mídia Apenas duas folhas de estilo Não mais de 10 scripts Até quatro fontes personalizadas Como muitos como 15 imagens
Pré-conectar aos domínios solicitados antes do LCP
As páginas criadas corretamente começam encontrando todos os domínios usados por esses 35 arquivos e, em seguida, usam a dica de recurso da pré-conexão. Shopify usa este padrão para pré-conectar a domínios críticos:
Isso permite que o navegador abra conexões antes que os arquivos sejam solicitados.
Pré-carregar e hospedar arquivos de fonte
A maioria dos sites dependem de fontes personalizadas e usam font-display: swap so th O texto fica visível até que a fonte personalizada seja baixada. PosterMyWall é um exemplo do padrão em que a fonte é pré-carregada e auto-hospedada. Esta é a maneira mais rápida de carregar e renderizar fontes personalizadas.
Se você precisa usar o Google Fonts, deve procurar usar o google-web-fonts-helper .
Evite fontes de ícone
O principal motivo para evitar fontes de ícone é que elas criam uma cadeia de solicitações . significa que o documento raiz deve carregar uma folha de estilo, que por sua vez carrega o arquivo de fonte do ícone antes de renderizar o ícone. Mas uma imagem simples com um atributo de altura e largura não tem dependências.
Se você precisar para usar uma fonte de ícone, Sproutsocial descreve um padrão útil ao pré-carregar a fonte e carregá-la de forma assíncrona. Além disso, eu recomendaria o pré-carregamento dos arquivos de fonte do ícone também.
Também vi a vantagem de adicionar regras @fontface inline também, o que remove o bloqueio de renderização all.css.
Estilos CSS críticos inline não são necessários
Fiquei surpreso ao descobrir que muitos sites não usam estilos inline. crie pequenos pacotes de CSS para carregar no
. Por exemplo, Loom pré-carrega folhas de estilo externas que totalizam cerca de 15 KB.Dito isso, Amazon AWS carrega uma única renderização de 74 KB bloco arquivo CSS king. Portanto, não use apenas um padrão porque o Lighthouse ou um post (como este) o recomenda.
Carregar pequenos pacotes JavaScript
Meu orçamento não recomenda mais do que 10 scripts antes da pintura de maior conteúdo. Isso não é permissão para carregar 10 arquivos enormes, mas os melhores sites carregam pequenos scripts (2 a 35 KB) na parte inferior da página aplicando atributos assíncronos ou deferir de maneira inteligente.
Vários sites usam Next.js , que fornece a capacidade de carregar scripts antes e depois de embarque interativo de JavaScript embutido, bem como a capacidade para scripts de carregamento lento (excelente para fornecedores terceirizados). Os scripts também são pré-carregados.
Se você tiver uma pilha de tecnologia diferente quando estiver scripts de pré-carregamento , preste atenção à ordem dos recursos.
Use SVG embutido para imagens pequenas e carregue lentamente o rest
Se você tiver imagens que podem ser SVGs relativamente pequenos, inline-as. Trello alinha todas as imagens SVG acima da dobra e carrega lentamente aquelas que estão fora da tela ou ocultas.
Eu também usei loading=eager for images acima da dobra. Sites como o Trello usam o atributo nativo loading=lazy, mas soluções JavaScript também foram observadas.
Use o elemento para exibir uma grande imagem hero
Nenhuma das páginas analisadas incluía um componente de imagem hero, então pesquisei e encontrei Trulia , que empregou um novo patte rn. Para começar, eles definem um PerformanceMark , que me indica um alto grau de intencionalidade.
Arriscando uma simplificação excessiva, observei que, para a imagem grande do herói, os desenvolvedores usaram o elemento
E, para emular uma imagem de fundo, eles usam a propriedade position para criar uma camada vários elementos
No desktop , a imagem de fundo grande aparece em 600 ms e o LCP ocorre em 900 ms. Em seguida, em um dispositivo móvel lento dispositivo , ele aparece em 1.8s e termina em 2.2s.
O segredo para a pintura de imagens é engenhoso.
O elemento tem uma configuração de estilo embutido, uma base 64 codificada e um JPG de 10 x 5 pixels como imagem de plano de fundo com a altura e a largura definidas para 100%. É por isso que pinta tão rapidamente e tem um efeito legal que faz com que a imagem passe de borrada a cristalina. Uau.
Carregue scripts de terceiros quando for interativo
Gerenciar fornecedores de terceiros é um desafio, especialmente quando o orçamento recomenda que apenas quatro scripts sejam carregados antes do LCP. Apesar disso, a empresa ainda pode usar fornecedores terceirizados, pois as páginas analisadas solicitaram que uma média de 103 arquivos de terceiros fossem totalmente carregados. Então, comecei a ver como as melhores páginas lidavam com scripts de fornecedores.
O melhor padrão carregava até quatro scripts (ou seja, gerenciador de tags, teste AB, RUM) antes de readyState ser interativo e, em seguida, carregava o restante após document.readyState ser concluído.
Se você empregar um gerenciador de tags, a cascata deve ser esperada. Ele carrega terceiros críticos antes de DOMContentLoaded, incluindo o script do gerenciador de tags. Em seguida, defina o acionador de evento do navegador para Janela carregada para todos os seus scripts restantes.
Isso descreve o melhor padrão. No entanto, sua situação pode exigir algo menos agressivo. A lição é assumir o controle de quando seus scripts estão sendo carregados, não apenas para os fornecedores, mas para todos os scripts, a fim de otimizar a cascata.
Padrões orientados a dados para melhorar o Core Web Vitals
Tenho certeza de que perdi algumas coisas ao abordar problemas de LCP, mas esses estudos de caso destacam por que Core Web Vitals (First Input Delay) não resultam em melhores padrões de JavaScript.
Além disso, eu não esperava esses sites de alta qualidade falharão no Cumulative Layout Shift. Mas, acho que encontraria mais padrões CSS se analisasse artigos com anúncios em vez de páginas de preços.
Essa análise não é uma surpresa. Todos esses padrões são bem documentados, com exceção do uso do elemento de imagem para uma grande imagem de herói.
Mas se você estiver escolhendo uma solução, eu recomendaria usar esses padrões, que são baseados em estudos de caso em vez de recomendações listadas pelo Lighthouse.
