Um estudo de caso sobre as mudanças que a GoDaddy implementou para melhorar a performance de milhões de sites, ajudando-os a alcançar boas pontuações no PageSpeed Insights e nas Core Web Vitals.
A GoDaddy é a maior plataforma de serviços do mundo para empreendedores em todo o mundo. Nossa missão é capacitar nossa comunidade global de mais de 20 milhões de clientes e empreendedores em todo o mundo, oferecendo a ajuda e as ferramentas necessárias para que eles cresçam on-line.
Em 2019, a GoDaddy lançou o Websites + Marketing com o compromisso de oferecer ferramentas e serviços fáceis de usar e ajudar os proprietários de empresas a alcançarem as próprias metas. O Websites + Marketing integra a criação de sites com ferramentas de marketing e e-commerce e os combina com orientações de primeira linha para ajudar os clientes a ter sucesso com os novos empreendimentos.
Desde o lançamento do Sites + Marketing, a performance é uma parte importante do produto e algo que tem sido monitorado e trabalhado ativamente. Neste artigo, vamos analisar a jornada da GoDaddy, que passou de usar testes de desempenho de laboratório para usar dados reais com as Principais métricas da Web e a série de melhorias feitas no produto para conseguir uma taxa de aprovação muito alta para os sites dos nossos clientes.
Acompanhar o desempenho com o Lighthouse
Usamos os dados do Lighthouse para acompanhar o desempenho. Sempre que um site é publicado na plataforma, medimos a performance dele usando nossa ferramenta interna chamada "Lighthouse4u", que oferece o Google Lighthouse como um serviço https://github.com/godaddy/lighthouse4u. Isso nos deu uma boa indicação de como os sites estavam se saindo em geral em um ambiente de laboratório.
Como os milhões de sites hospedados na nossa plataforma têm uma ampla variedade de recursos e conteúdo, foi importante combinar os dados de performance com metadados sobre cada site testado (como o modelo usado, o tipo de widgets renderizados e assim por diante). Isso nos permitiu tirar conclusões sobre quais recursos do site tinham desempenho mais baixo e também fornecer insights sobre onde procurar melhorias.
Por exemplo, isso nos ajudou a identificar que o "modal pop-up" estava tendo um impacto negativo na velocidade da página. Os sites com o recurso tiveram uma performance 12 pontos menor do que os sites sem o recurso. Depois de fazer atualizações no código para adiar o carregamento do JavaScript, melhoramos nossa pontuação no Lighthouse em dois pontos. Conseguimos aplicar esse aprendizado a outros recursos, como o "banner de cookies" que é renderizado logo após o carregamento da página.
Além de analisar sites problemáticos com base nos recursos, realizamos uma análise do nosso pacote JavaScript e observamos que uma grande parte do tamanho dele veio de dependências externas (immutable.js e draft.js). Reduzimos o tamanho do pacote reestruturando os consumidores para carregar as dependências de maneira lenta. Isso resultou em uma queda de mais de 50% no tamanho do pacote JavaScript comum, que passou de mais de 200 KB para cerca de 90 KB (minimizado). O tamanho menor do pacote permitiu que o navegador carregasse recursos externos e executasse scripts críticos mais cedo no ciclo de vida inicial de carregamento do site, levando a ganhos na Maior exibição de conteúdo (LCP) e no First Input Delay (FID).
Graças aos nossos esforços contínuos, a pontuação média do Lighthouse para sites de clientes passou de cerca de 40 pontos em novembro de 2020 para mais de 70 pontos em maio de 2021. No entanto, nem todas as nossas tentativas funcionaram e, às vezes, ficamos surpresos quando os resultados não eram consistentes entre o que foi testado em ambientes de teste locais e os resultados que recebemos no campo. Os resultados do laboratório foram muito úteis, mas era hora de se concentrar nas experiências reais dos usuários observadas no campo.
Como acompanhar dados de usuários reais com as Core Web Vitals
Depois de adicionar a biblioteca web-vitals aos sites dos nossos clientes, conseguimos medir dados em dispositivos reais de visitantes reais, em que o hardware, a velocidade da rede e a interação do usuário (como rolagem ou clique) não estão em uma base consistente, como em um ambiente de laboratório usando o Lighthouse. Esse foi um grande passo na direção certa, porque agora tínhamos dados que representavam a experiência dos visitantes do nosso site.
Foco no nosso elo mais fraco: Cumulative Layout Shift (CLS)
A análise de novos dados nos deu uma nova perspectiva sobre o que precisava ser feito para melhorar a velocidade do site. Devido ao trabalho feito para melhorar a pontuação do Lighthouse, nosso LCP de percentil 75 foi de 860 ms, e o FID no mesmo limite foi abaixo de 10 ms. Assim, tivemos uma alta taxa de aprovação para essas métricas nos sites do nosso cliente: 78% e 98%, respectivamente. No entanto, os números de Shift de layout cumulativo (CLS, na sigla em inglês) parecem bastante diferentes do que estávamos acostumados com o Lighthouse. O CLS na 75ª percentila foi de 0,17, acima do limite de 0,1 para "aprovação". Assim, a taxa de aprovação foi de apenas 47% em todos os nossos sites.
Essa métrica reduziu nossa taxa de aprovação geral para 40%. Por isso, definimos uma meta ambiciosa para aumentar esse número para mais de 60% até o final de agosto de 2021. Para isso, precisamos nos concentrar na CLS.
Na vida real, os usuários interagem com a página e rolam a tela para além do conteúdo "acima da dobra", algo que as principais métricas da Web capturam melhor. Devido à variabilidade na forma como os usuários interagem com o site durante o carregamento inicial, o CLS difere dos dados de laboratório e de campo.
O caminho para a aprovação em todas as Core Web Vitals
Para melhorar a performance, é preciso testar e errar, e nem sempre cada tentativa funciona como esperado. No entanto, aqui estão algumas melhorias que nos ajudaram a alcançar nossos objetivos.
Reservar espaço para carregar imagens melhorou drasticamente nossa pontuação de CLS, porque impede que o conteúdo abaixo das imagens se mova. Usamos a propriedade aspect-ratio do CSS para resolver esse problema nos navegadores compatíveis. Para aqueles que não têm, carregamos uma imagem de marcador de posição transparente que foi armazenada em cache e tem apenas alguns bytes, carregando quase instantaneamente.
Esse comportamento genérico permitiu que calculássemos a altura da imagem final durante a renderização no servidor com base na largura da janela de visualização e na proporção da imagem. Isso resultou em marcação HTML com espaço vertical reservado adequadamente para a imagem final. A melhoria foi particularmente perceptível em dispositivos móveis, já que as imagens são renderizadas para a extensão total das visualizações de dispositivos móveis.
Alguns componentes nos sites dos nossos clientes têm conteúdo dinâmico (por exemplo, uma lista de avaliações externas de clientes) e não podem ser convertidos em CSS puro para aproveitar os benefícios de desempenho da renderização do lado do servidor. Essas são áreas difíceis de melhorar as mudanças de layout porque o conteúdo (e, portanto, a altura) varia. Nesses casos, o componente foi adicionado a um contêiner com uma min-height aplicada, predeterminada com base na observação da altura média de cada um dos componentes específicos. O min-height é removido quando a renderização do componente dinâmico interno é concluída. Embora não seja perfeita, essa solução nos permitiu reduzir muito a mudança de layout.
Enquanto nos concentramos nas melhorias da CLS, continuamos trabalhando na LCP. Em muitos sites, as imagens são as maiores responsáveis pela LCP, e para nós, essa era uma área óbvia de melhoria. Fizemos melhorias no carregamento lento de imagens usando IntersectionObserver, mas percebemos que os tamanhos das imagens não estavam definidos da maneira mais otimizada para cada ponto de interrupção (dispositivo móvel, tablet, computador, computador grande). Atualizamos nosso código de geração de imagens para fixar e dimensionar imagens por ponto de interrupção e, em seguida, dimensionar a resolução com base na densidade de pixels. Por exemplo, o tamanho de uma imagem grande específica foi reduzido de 192 KB para 102 KB.
Para renderizar rapidamente sites em dispositivos com conexões de rede ruins, adicionamos um código para reduzir dinamicamente a qualidade da imagem com base na velocidade da conexão. Isso pode ser feito usando a propriedade downlink retornada por navigator.connection. Aplicamos parâmetros de consulta com base no URL para reduzir a qualidade da imagem usando nossa API de recursos com base nessas condições de rede.
Várias seções dos sites dos nossos clientes são carregadas dinamicamente. Como sabemos quais seções serão renderizadas em um determinado site quando ele for publicado, usamos a dica de recurso rel=preconnect para inicializar a conexão e as verificações necessárias com antecedência. Também usamos dicas de recursos para carregar fontes e outros recursos importantes rapidamente.
Ao criar sites, os clientes adicionam várias seções que podem ter scripts inline para permitir diferentes funcionalidades. Ter esses scripts inline em toda a página HTML nem sempre é o ideal para o desempenho. Decidimos externalizar esses scripts para permitir que o navegador carregue e analise o conteúdo do script de forma assíncrona. Os scripts recém-externalizados também podem ser compartilhados entre páginas. Isso permitiu ganhos de desempenho adicionais na forma de armazenamento em cache do navegador e da CDN. Mantivemos scripts essenciais inline para que o navegador os analisasse e os executasse mais rapidamente.
Resultados
O foco na CLS valeu a pena. Nossa taxa de aprovação nas Core Web Vitals aumentou de cerca de 40% para quase 70%: uma melhoria de 75%.
À medida que os usuários voltam à nossa plataforma para fazer atualizações e republicar os sites, eles recebem as melhorias de desempenho mais recentes. Como resultado, o número de sites que "atendem aos Core Web Vitals" tem crescido constantemente, conforme mostrado no gráfico abaixo:
Conclusões
A descoberta de áreas para melhorias de performance e o acompanhamento do progresso dependem muito das ferramentas usadas para medição. Embora o Lighthouse fosse útil para medir a performance acima da dobra em uma "configuração de laboratório", ele não capturava com precisão os problemas de desempenho que ocorriam apenas com as interações do usuário (como rolar a página).
O rastreamento das Core Web Vitals reais com metadados nos permitiu visualizar, segmentar e medir o impacto das nossas melhorias. A jornada para melhorar as pontuações das Core Web Vitals permitiu que a equipe identificasse e substituísse padrões não eficientes encontrados em toda a base de código. Às vezes, mudanças promissoras não têm quase o impacto esperado, outras vezes acontece o oposto. O mundo não é perfeito, então você precisa continuar tentando.