Um estudo de caso das alterações implementadas pela GoDaddy para melhorar o desempenho 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 para empreendedores do mundo todo. Nossa missão é capacitar nossa comunidade mundial de mais de 20 milhões de clientes, e empreendedores de todos os lugares, oferecendo a eles toda a ajuda e as ferramentas necessárias para crescer on-line.
Em 2019, a GoDaddy lançou a Sites + Marketing com o compromisso de oferecer ferramentas e serviços fáceis de usar e ajudar os proprietários de empresas a alcançar as próprias metas. A Sites + Marketing integra a criação de sites às ferramentas de marketing e e-commerce e inclui a melhor orientação da categoria para ajudar os clientes a ter sucesso com os novos empreendimentos.
Desde o lançamento do site + marketing, a performance tem sido uma parte importante do produto e algo que tem sido monitorado e trabalhado ativamente. Neste artigo, vamos analisar a jornada do GoDaddy desde o uso de testes de desempenho no laboratório até o uso de dados reais com as Core Web Vitals. Além disso, vamos analisar a série de melhorias feitas no produto para alcançar uma taxa de aprovação muito alta nos sites dos nossos clientes.
Como acompanhar o desempenho com o Lighthouse
Usamos os dados do Lighthouse para acompanhar o desempenho. Sempre que um site é publicado na plataforma, medimos o desempenho 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 do desempenho geral dos sites em um laboratório.
Como os milhões de sites que hospedamos em nossa plataforma têm uma ampla variedade de recursos e conteúdos, era importante combinar dados de desempenho com metadados sobre cada site que estava sendo testado (como modelo usado, tipo de widget renderizado etc.). Isso nos permitiu tirar conclusões sobre quais recursos do site apresentaram menor desempenho, além de fornecer informações 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 um desempenho 12 pontos menor do que sem esse recurso. Depois de fazer atualizações no código para adiar o carregamento do JavaScript, melhoramos nossa pontuação do Lighthouse em 2 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 em recursos, conduzimos uma análise do pacote JavaScript e vimos que uma grande parte do tamanho dele veio de dependências externas (imutable.js e rascunho.js). Reduzimos o tamanho do pacote reestruturando os consumidores para dependências de carregamento lento sob demanda. Isso resultou em uma queda de mais de 50% no tamanho do pacote JavaScript comum, que passou de 200 KB para cerca de 90 KB (reduzido). O tamanho do pacote menor permitiu que o navegador carregasse recursos externos e executasse scripts essenciais mais cedo no ciclo de carregamento do site inicial, levando a ganhos em Maior exibição de conteúdo (LCP) e na latência na primeira entrada (FID, na sigla em inglês).
Graças aos nossos esforços contínuos, a pontuação média do site dos clientes no Lighthouse 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 nem sempre eram consistentes entre o que foi testado em ambientes de teste locais e os resultados que tínhamos em 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.
Rastrear dados reais de usuários 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, onde o hardware, a velocidade da rede e a interação do usuário (como rolagem ou clique) não estavam em um valor de referência consistente como no laboratório com o Lighthouse. Esse foi um grande passo na direção certa, já que agora tínhamos dados representativos da experiência dos visitantes do site.
Foco no nosso elo mais fraco: Mudança de layout cumulativa (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, nossa LCP de 75o percentil foi de 860 ms e nossa FID no mesmo limite ficou abaixo de 10 ms. Por isso, tivemos uma alta taxa de aprovação nessas métricas nos sites dos nossos clientes: 78% e 98%, respectivamente. No entanto, os números da Mudança de layout cumulativa (CLS) parecem bem diferentes dos números que estavam acostumados no Lighthouse. Nossa CLS no 75o percentil foi de 0,17, acima do limite de 0,1 para "aprovado". Portanto, nossa 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%, então decidimos definir uma meta ambiciosa para passar esse número para mais de 60% até o fim de agosto de 2021. Para isso, precisaríamos nos concentrar na CLS.
Na vida real, os usuários interagem com a página e rolam para além do conteúdo "acima da dobra", algo que as Core Web Vitals capturam melhor. Devido à variação na forma como os usuários interagem com o site durante o carregamento inicial, a CLS foi diferente dos dados de laboratório e de campo.
O caminho para passar em todas as Core Web Vitals
Melhorar o desempenho requer tentativa e erro, e toda tentativa nem sempre funciona como esperado. No entanto, confira a seguir algumas melhorias que nos ajudaram a alcançar nossas metas.
A reserva de espaço para carregar imagens melhorou drasticamente nossa pontuação de CLS, já que evita que o conteúdo abaixo das imagens mude. Usamos a propriedade aspect-ratio do CSS (link em inglês) para resolver esse problema em navegadores compatíveis. Para aqueles que não o fizeram, carregamos uma imagem transparente de marcador que foi armazenada em cache e com apenas alguns bytes de tamanho, carregando assim quase instantaneamente.
Esse comportamento genérico da imagem nos permitiu pré-calcular a altura da imagem final durante a renderização do lado do servidor, com base na largura da janela de visualização e na proporção da imagem. Isso resultou em uma marcação HTML com espaço vertical reservado adequadamente para a imagem final. A melhoria foi notada especialmente em dispositivos móveis, já que as imagens são renderizadas em todas as janelas de visualização de dispositivos móveis.
Alguns componentes dos 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 em que é difícil melhorar as mudanças de layout, porque o conteúdo (altura) varia. Nesses casos, envolvemos o componente em 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 as mudanças de layout.
Enquanto nos concentramos nas melhorias da CLS, continuamos trabalhando na LCP. Em muitos sites, as imagens são as principais responsáveis pela contribuição para a LCP e, para nós, era uma área óbvia de melhorias. Fizemos melhorias no carregamento lento de imagens usando IntersectionObserver, mas percebemos que os tamanhos de imagem não estavam definidos da maneira mais adequada para cada ponto de interrupção (dispositivo móvel, tablet, computador, computador grande). Por isso, atualizamos nosso código de geração de imagens para limitar e dimensionar imagens por ponto de interrupção e depois dimensionar novamente a resolução com base na densidade de pixels. Por exemplo, isso reduziu o tamanho de uma imagem grande específica de 192 KB para 102 KB.
Para renderizar rapidamente sites em dispositivos com conexões de rede fracas, adicionamos 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 das imagens por meio da nossa API de recursos de acordo com as condições da rede.
Várias seções dos sites dos nossos clientes são carregadas dinamicamente. Como sabemos quais seções vão ser renderizadas em um determinado site quando ele for publicado, usamos a dica de recurso rel=preconnect (link em inglês) para inicializar a conexão e os handshakes necessários com antecedência. Também usamos dicas para carregar fontes e outros recursos importantes rapidamente.
Ao criar os 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 é ideal para o desempenho. Decidimos externalizar esses scripts para permitir que o navegador carregasse e analisasse o conteúdo do script de forma assíncrona. Scripts recém-externos também podem ser compartilhados entre páginas. Isso permitiu ganhos adicionais de desempenho na forma de cache do navegador e da CDN. Mantivemos os scripts essenciais em linha para que o navegador os analise e execute com mais rapidez.
Resultados
Ao concentrar nossos esforços na CLS valem a pena, a taxa de aprovação nas Core Web Vitals passou de cerca de 40% para quase 70%: uma melhoria de 75%.
À medida que os usuários voltam à plataforma para fazer atualizações e republicar os sites, eles recebem as últimas melhorias de desempenho. Por isso, o número de sites que "aprovam as Core Web Vitals" vem crescendo constantemente, conforme mostrado no gráfico abaixo:
Conclusões
Encontrar áreas para melhorias na performance e acompanhar o progresso com sucesso depende muito das ferramentas usadas para medição. Embora o Lighthouse tenha sido útil para medir o desempenho acima da dobra em um "laboratório", ele não capturava com precisão os problemas de desempenho ocorridos somente nas interações do usuário (como a rolagem da página).
Acompanhar as 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 substituisse padrões de não desempenho encontrados em toda a nossa base de código. Mudanças promissoras não tiveram quase o impacto esperado, outras vezes aconteceu o contrário. O mundo não é novo, então você tem que continuar tentando.