Um estudo de caso sobre algumas mudanças importantes introduzidas no Wix para melhorar o desempenho de carregamento de milhões de sites, preparando o caminho para que eles recebam boas pontuações no PageSpeed Insights e nas Core Web Vitals.
Graças ao uso de padrões do setor, provedores de nuvem e recursos de CDN, combinados com uma reformulação considerável do ambiente de execução do nosso site, a porcentagem de sites do Wix que alcançaram boas pontuações no 75o percentil em todas as métricas das Core Web Vitals mais do que triplicou ano após ano, de acordo com dados do CrUX e do HTTPArchive.
A Wix adotou uma cultura orientada pelo desempenho, e outras melhorias continuarão sendo lançadas para os usuários. Com o foco nos KPIs de performance, esperamos ver o número de sites que ultrapassam os limites das Core Web Vitals aumentar.
Visão geral
O mundo do desempenho é incrivelmente complexo, com muitas variáveis e complexidades. Pesquisas mostram que a velocidade do site tem um impacto direto nas taxas de conversão e nas receitas para as empresas. Nos últimos anos, o setor dedicou mais ênfase à visibilidade do desempenho e a tornar a Web mais rápida. A partir de maio de 2021, os indicadores de experiência na página serão incluídos na classificação da Pesquisa Google.
O único desafio do Wix é oferecer suporte a milhões de sites, alguns dos quais foram criados há muitos anos e não são atualizados desde então. Temos várias ferramentas e artigos para ajudar os usuários sobre o que eles podem fazer para analisar e melhorar o desempenho dos sites.
O Wix é um ambiente gerenciado e nem tudo está nas mãos do usuário. O compartilhamento de infraestruturas comuns apresenta muitos desafios para todos esses locais, mas também abre oportunidades para grandes melhorias em toda a empresa, ou seja, aproveitando as economias de escala.
Como falar em uma linguagem comum
Uma das principais dificuldades com o desempenho é encontrar uma terminologia comum para discutir diferentes aspectos da experiência do usuário, considerando o desempenho técnico e percebido. Usar uma linguagem comum bem definida dentro da organização nos permitiu discutir e categorizar facilmente as diferentes partes técnicas e compensações, esclareceu nossos relatórios de desempenho e ajudou a entender quais aspectos precisamos nos concentrar primeiro.
Ajustamos todas as nossas discussões internas e de monitoramento para incluir métricas padrão do setor, como as Métricas da Web, que incluem:
Complexidade do site e pontuações de desempenho
É muito fácil criar um site com carregamento instantâneo, desde que você torne tudo muito simples usando apenas HTML e o veicule por meio de uma CDN.
No entanto, a realidade é que os sites estão ficando cada vez mais complexos e sofisticados, operando mais como aplicativos em vez de documentos e com suporte a funcionalidades, como blogs, soluções de comércio eletrônico, código personalizado etc.
O Wix oferece uma grande variedade de modelos, permitindo que os usuários criem facilmente um site com muitos recursos comerciais. Esses recursos extras geralmente têm alguns custos de desempenho.
A jorna
No início, havia HTML
Toda vez que uma página da Web é carregada, ela sempre começa com uma solicitação inicial a um URL para recuperar o documento HTML. Essa resposta HTML aciona todas as solicitações adicionais do cliente e a lógica do navegador para executar e renderizar seu site. Essa é a parte mais importante do carregamento da página, porque nada acontece até o início da resposta chegar (conhecido como TTFB: tempo para o primeiro byte).
No passado: renderização do lado do cliente (CSR)
Ao operar sistemas de grande escala, você sempre tem vantagens e desvantagens que precisa considerar, como desempenho, confiabilidade e custos. Até alguns anos atrás, o Wix usava a renderização do lado do cliente (CSR, na sigla em inglês), em que o conteúdo HTML real era gerado pelo JavaScript no lado do cliente (ou seja, no navegador). Dessa forma, pudemos oferecer suporte a uma alta escala de sites sem custos operacionais enormes com o back-end.
A CSR nos permitiu usar um documento HTML comum, que estava essencialmente vazio. Ele só acionou o download do código e dos dados necessários, que foram usados para gerar o HTML completo no dispositivo cliente.
Hoje: renderização do lado do servidor (SSR)
Há alguns anos, fizemos a transição para a renderização do lado do servidor (SSR, na sigla em inglês), já que ela era benéfica para a SEO e o desempenho, melhorando os tempos de visibilidade da página inicial e garantindo uma melhor indexação para mecanismos de pesquisa que não têm suporte total à execução de JavaScript.
Essa abordagem melhorou a experiência de visibilidade, especialmente em conexões/dispositivos mais lentos, e abriu as portas para outras otimizações de desempenho. No entanto, isso também significava que, para cada solicitação de página da Web, uma resposta HTML exclusiva era gerada imediatamente, o que está longe do ideal, especialmente para sites com uma grande quantidade de visualizações.
Introdução ao armazenamento em cache em vários locais
O HTML de cada site era basicamente estático, mas tinha algumas ressalvas:
- Ele muda com frequência. Sempre que um usuário edita o site ou faz alterações nos dados dele, como no inventário da loja do site.
- Tinha determinados dados e cookies que eram específicos para o visitante, o que significa que duas pessoas que acessam o mesmo site veriam um HTML um pouco diferente. Por exemplo, para oferecer suporte a recursos de produtos, como lembrar quais itens um visitante colocou no carrinho, o chat que o visitante iniciou com a empresa mais cedo e muito mais.
- Nem todas as páginas podem ser armazenadas em cache. Por exemplo, uma página com código de usuário personalizado, que exibe a hora atual como parte do documento, não está qualificada para armazenamento em cache.
Inicialmente, adotamos a abordagem relativamente segura de armazenamento em cache do HTML sem dados de visitante e, em seguida, modificamos apenas partes específicas da resposta HTML para cada visitante, para cada ocorrência em cache.
Solução de CDN interna
Fizemos isso com a implantação de uma solução interna: usando o Cache HTTP Varnish para proxy e armazenamento em cache, o Kafka para mensagens de invalidação e um serviço baseado em Scala/Netty que faz proxy dessas respostas HTML, mas muda o HTML e adiciona cookies e dados específicos do visitante à resposta em cache.
Essa solução nos permitiu implantar esses componentes slim em muito mais localizações geográficas e várias regiões de provedor de nuvem, que estão espalhados por todo o mundo. Em 2019, lançamos mais de 15 novas regiões e, gradualmente, ativamos o armazenamento em cache em mais de 90% das nossas visualizações de página qualificadas para esse processo. A exibição de sites de outros locais reduziu a latência da rede entre os clientes e os servidores que veiculam a resposta HTML, aproximando o conteúdo dos visitantes do site.
Também começamos a armazenar algumas respostas da API somente leitura em cache usando a mesma solução e invalidando o cache em qualquer alteração no conteúdo do site. Por exemplo, a lista de postagens de blog no site é armazenada em cache e invalidada quando uma postagem é publicada/modificada.
Reduzir complexidades
Implementar o armazenamento em cache melhorou o desempenho de forma substancial, principalmente nas fases TTFB e FCP, e melhorou nossa confiabilidade ao exibir o conteúdo de um local mais próximo do usuário final.
No entanto, a necessidade de modificar o HTML para cada resposta introduziu uma complexidade desnecessária que, se removida, representava uma oportunidade para outras melhorias de desempenho.
Armazenamento em cache do navegador (e preparações para CDNs)
Aprox. 13%
As solicitações HTML são veiculadas diretamente do cache do navegador, economizando muita largura de banda e reduzindo os tempos de carregamento de visualizações repetidas.
A próxima etapa era remover esses dados específicos do visitante do HTML totalmente e recuperá-los de um endpoint separado, chamado pelo cliente para essa finalidade, depois que o HTML chegar.
Migramos cuidadosamente esses dados e cookies para um novo endpoint, que é chamado em cada carregamento de página, mas retorna um JSON fino, necessário apenas para o processo de hidratação, para alcançar toda a interatividade da página.
Isso nos permitiu ativar o armazenamento em cache do HTML no navegador, o que significa que os navegadores agora salvam a resposta HTML para visitas repetidas e apenas chamam o servidor para confirmar que o conteúdo não foi alterado. Isso é feito usando a ETag HTTP, que é basicamente um identificador atribuído a uma versão específica de um recurso HTML. Se o conteúdo ainda for o mesmo, uma resposta 304 Not Modified será enviada pelos nossos servidores ao cliente, sem um corpo.
Além disso, essa mudança significa que nosso HTML não é mais específico para visitantes e não contém cookies. Em outras palavras, ele pode ser armazenado em cache em qualquer lugar, o que permite o uso de provedores de CDN com uma presença geográfica muito melhor em centenas de locais ao redor do mundo.
DNS, SSL e HTTP/2
Com o armazenamento em cache ativado, os tempos de espera foram reduzidos e outras partes importantes da conexão inicial se tornaram mais substanciais. Aprimorar nossa infraestrutura de rede e monitoramento nos permitiu aprimorar os tempos de DNS, conexão e SSL.
O HTTP/2 foi ativado para todos os domínios do usuário, reduzindo a quantidade de conexões necessárias e a sobrecarga de cada nova conexão. Essa foi uma mudança relativamente fácil de implantar, aproveitando os benefícios de desempenho e resiliência que vêm com o HTTP/2.
Compactação Brotli (vs. gzip)
21 a 25%
de redução do tamanho médio da transferência de arquivos
Tradicionalmente, todos os arquivos eram compactados usando a compactação gzip, que é a opção de compactação de HTML mais comum na Web. Esse protocolo de compactação foi implementado inicialmente há quase 30 anos.
A compactação Brutli (link em inglês) mais recente apresenta melhorias de compactação quase sem compensações e está se tornando gradualmente mais conhecida, conforme descrito no capítulo anual de compactação da Almanaque da Web. Ela é compatível com todos os principais navegadores há algum tempo.
Ativamos o suporte ao Brotli nos nossos proxies nginx nas bordas para todos os clientes com suporte.
A mudança para a compactação com o Brotli reduziu os tamanhos médios de transferência de arquivos em 21% a 25%, o que reduziu o uso da largura de banda e melhorou os tempos de carregamento.
Redes de fornecimento de conteúdo (CDNs)
Seleção de CDN dinâmica
No Wix, sempre usamos CDNs para exibir todo o código e imagens JavaScript nos sites do usuário.
Recentemente, nos integramos a uma solução do nosso provedor de DNS para selecionar automaticamente a CDN de melhor desempenho de acordo com a rede e a origem do cliente. Isso nos permite disponibilizar os arquivos estáticos do melhor local para cada visitante e evitar problemas de disponibilidade em uma determinada CDN.
Em breve... domínios de usuário veiculados por CDNs
A peça final do quebra-cabeça serve para a última parte, e mais essencial, por meio de uma CDN: o HTML do domínio do usuário.
Conforme descrito acima, criamos nossa própria solução interna para armazenar em cache e exibir os resultados de HTML e API específicos do site. A manutenção dessa solução em tantas regiões novas também tem custos operacionais, e a adição de novas unidades se torna um processo que precisamos gerenciar e otimizar continuamente.
No momento, estamos nos integrando a vários provedores de CDN para oferecer suporte à exibição de todo o site do Wix diretamente dos locais de CDN para melhorar a distribuição dos nossos servidores em todo o mundo e, assim, melhorar ainda mais os tempos de resposta. Isso é um desafio devido à grande quantidade de domínios que disponibilizamos, que exigem o término SSL na borda.
A integração com CDNs aproxima os sites da Wix do que nunca do cliente e oferece mais melhorias na experiência de carregamento, incluindo tecnologias mais recentes, como HTTP/3, sem exigir mais esforço da nossa parte.
Algumas palavras sobre o monitoramento de desempenho
Se você administra um site do Wix, provavelmente está se perguntando como isso se reflete nos resultados de desempenho do site do Wix e como comparamos com outras plataformas de sites.
A maior parte do trabalho feito acima foi implantada no ano passado, e parte ainda está sendo implementada.
O Web Almanac da HTTPArchive publicou recentemente a edição 2020 (link em inglês), que inclui um capítulo excelente sobre a experiência do usuário em CMS. Lembre-se de que muitos dos números descritos neste artigo são da meia de 2020.
Esperamos receber o relatório atualizado em 2021 e estamos monitorando ativamente os relatórios do CrUX dos nossos sites e nossas métricas de desempenho internas.
Temos o compromisso de melhorar continuamente o tempo de carregamento e oferecer aos usuários uma plataforma em que eles possam criar sites como quiserem, sem comprometer a performance.
O DebugBear lançou recentemente uma análise de desempenho do criador de sites muito interessante, que aborda algumas das áreas mencionadas acima e analisa o desempenho de sites muito simples criados em cada plataforma. Este site foi criado há quase dois anos e não foi modificado desde então, mas a plataforma está sempre melhorando, e o desempenho do site, além disso, pode ser conferido ao consultar os dados ao longo de um ano e meio.
Conclusão
Esperamos que nossa experiência inspire você a adotar uma cultura voltada ao desempenho na sua organização e que os detalhes acima sejam úteis e aplicáveis à sua plataforma ou local.
Para resumir:
- Escolha um conjunto de métricas que você possa rastrear de forma consistente usando ferramentas endossadas pelo setor. Recomendamos as Core Web Vitals.
- Use o armazenamento em cache do navegador e as CDNs.
- Migre para HTTP/2 (ou HTTP/3, se possível).
- Use a compactação Brotli.
Agradecemos por conhecer nossa história. Convidamos você a fazer perguntas, compartilhar ideias no Twitter e no GitHub e participar das conversas sobre o desempenho na Web nos seus canais favoritos.