Um estudo de caso sobre algumas mudanças importantes introduzidas no Wix para melhorar a performance de carregamento de milhões de sites, abrindo caminho para que eles recebam boas pontuações no PageSpeed Insights e nas Core Web Vitals.
Graças à utilização de padrões do setor, provedores de nuvem e recursos de CDN, combinados com uma grande reescrita do tempo de execução do nosso site, a porcentagem de sites do Wix que alcançaram boas pontuações de percentis de 75% em todas as métricas do Core Web Vitals mais que triplicou ano após ano, de acordo com os dados do CrUX e do HTTPArchive.
O Wix adotou uma cultura orientada à performance, e outras melhorias vão continuar sendo lançadas para os usuários. À medida que nos concentramos nos KPIs de performance, esperamos que o número de sites que atendem aos limites das Core Web Vitals aumente.
Visão geral
O mundo da performance é lindamente 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 das empresas. Nos últimos anos, a indústria tem dado mais ênfase à visibilidade de desempenho e à velocidade da Web. A partir de maio de 2021, os indicadores de experiência na página vão ser incluídos na classificação da Pesquisa Google.
O desafio único do Wix é oferecer suporte a milhões de sites, alguns dos quais foram criados há muitos anos e não foram atualizados desde então. Temos várias ferramentas e artigos para ajudar nossos usuários a analisar e melhorar a performance 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 sites, mas também abre oportunidades para grandes melhorias em todos os aspectos, ou seja, aproveitando as economias de escala.
Falar em um idioma comum
Uma das principais dificuldades com a performance é encontrar uma terminologia comum para discutir diferentes aspectos da experiência do usuário, considerando a performance técnica e percebida. O uso de uma linguagem comum e bem definida na organização nos permitiu discutir e categorizar facilmente as diferentes partes técnicas e compensações, esclarecer nossos relatórios de desempenho e ajudou muito a entender quais aspectos devemos melhorar primeiro.
Ajustamos todas as nossas discussões internas e de monitoramento para incluir métricas padrão do setor, como os Web Vitals, que incluem:
Pontuações de desempenho e complexidade do site
É muito fácil criar um site que carrega instantaneamente, desde que você o torne muito simples usando apenas HTML e o disponibilize por uma CDN.
No entanto, a realidade é que os sites estão cada vez mais complexos e sofisticados, funcionando mais como aplicativos do que documentos e oferecendo suporte a funcionalidades como blogs, soluções de e-commerce, código personalizado etc.
A Wix oferece uma grande variedade de modelos, permitindo que os usuários criem facilmente um site com muitos recursos de negócios. Esses recursos adicionais geralmente têm alguns custos de desempenho.
A jorna
No começo, havia o HTML
Sempre que uma página da Web é carregada, ela começa com uma solicitação inicial para um URL para recuperar o documento HTML. Essa resposta HTML aciona todas as solicitações de 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é que o início da resposta chegue (conhecido como TTFB, ou tempo para o primeiro byte).
O passado: renderização do lado do cliente (CSR)
Ao operar sistemas em grande escala, você sempre precisa considerar compensações, 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 por JavaScript no lado do cliente (ou seja, no navegador), permitindo que oferecêssemos suporte a um grande número de sites sem ter custos operacionais de back-end muito altos.
O CSR nos permitiu usar um documento HTML comum, que estava praticamente vazio. Ele apenas 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), porque isso era benéfico para SEO e performance, melhorando os tempos de visibilidade inicial da página e garantindo uma melhor indexação para mecanismos de pesquisa que não têm suporte total para a execução de JavaScript.
Essa abordagem melhorou a experiência de visibilidade, especialmente em dispositivos/conexões mais lentos, e abriu caminho para outras otimizações de desempenho. No entanto, isso também significa que, para cada solicitação de página da Web, uma resposta HTML exclusiva era gerada em tempo real, o que é muito diferente do ideal, principalmente para sites com uma grande quantidade de visualizações.
Introdução do armazenamento em cache em vários locais
O HTML de cada site era basicamente estático, mas tinha algumas ressalvas:
- Ela muda com frequência. Sempre que um usuário edita o site ou faz mudanças nos dados do site, como no inventário da loja do site.
- Ele tinha alguns dados e cookies específicos para o visitante, ou seja, duas pessoas que acessam o mesmo site teriam um HTML um pouco diferente. Por exemplo, para oferecer suporte a recursos de produtos, como lembrar quais itens um visitante colocou no carrinho, ou o chat que o visitante iniciou com a empresa anteriormente, entre outros.
- Nem todas as páginas podem ser armazenadas em cache. Por exemplo, uma página com código de usuário personalizado, que mostra a hora atual como parte do documento, não está qualificada para o armazenamento em cache.
Inicialmente, adotamos a abordagem relativamente segura de armazenar o HTML em cache sem dados do visitante e, em seguida, modificamos partes específicas da resposta do HTML em tempo real para cada visitante, para cada acerto de cache.
Solução CDN interna
Fizemos isso implantando uma solução interna: usando o Varnish HTTP Cache 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 modifica o HTML e adiciona dados e cookies específicos do visitante à resposta em cache.
Essa solução nos permitiu implantar esses componentes slim em muitos outros locais geográficos e várias regiões de provedores de nuvem espalhadas pelo mundo. Em 2019, lançamos mais de 15 novas regiões e ativamos gradualmente o armazenamento em cache para mais de 90% das visualizações de página que estavam qualificadas. A veiculação de sites em 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 em cache algumas respostas de API somente leitura usando a mesma solução e invalidando o cache em qualquer alteração no conteúdo do site. Por exemplo, a lista de postagens do blog no site é armazenada em cache e invalidada quando uma postagem é publicada/modificada.
Redução da complexidade
A implementação do armazenamento em cache melhorou significativamente a performance, principalmente nas fases de TTFB e FCP, e melhorou nossa confiabilidade ao veicular 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, apresentou uma oportunidade para mais melhorias no desempenho.
Armazenamento em cache do navegador (e preparações para CDNs)
~ 13%
As solicitações HTML são atendidas diretamente do cache do navegador, economizando muita largura de banda e reduzindo os tempos de carregamento para visualizações repetidas
A próxima etapa foi remover esses dados específicos do visitante do HTML inteiramente e recuperá-los de um endpoint separado, chamado pelo cliente para essa finalidade, depois que o HTML chegou.
Migramos esses dados e cookies cuidadosamente para um novo endpoint, que é chamado em cada carregamento de página, mas retorna um JSON simples, que é necessário apenas para o processo de hidratação, para alcançar a interatividade total 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 do HTML para visitas repetidas e só chamam o servidor para validar se o conteúdo não mudou. 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 o visitante e não contém cookies. Em outras palavras, ele pode ser armazenado em cache em qualquer lugar, abrindo as portas para o uso de provedores de CDN que têm 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. Melhorar nossa infraestrutura de rede e o monitoramento nos permitiu melhorar os tempos de DNS, conexão e SSL.
O HTTP/2 foi ativado para todos os domínios de usuário, reduzindo a quantidade de conexões necessárias e a sobrecarga que vem com cada nova conexão. Essa foi uma mudança relativamente fácil de implantar, aproveitando os benefícios de desempenho e resiliência que vem com o HTTP/2.
Compactação Brotli (em comparação com o gzip)
21 a 25%
Redução do tamanho médio da transferência de arquivos
Tradicionalmente, todos os nossos 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 nova compactação Brotli introduz melhorias na compactação com quase nenhuma perda e está se tornando cada vez mais popular, conforme descrito no capítulo sobre compactação do Web Almanac anual. Ele tem suporte de todos os principais navegadores há algum tempo.
Ativamos o suporte ao Brotli nos nossos proxies nginx nas bordas para todos os clientes que oferecem suporte a ele.
A mudança para a compactação Brotli reduziu o tamanho médio da transferência de arquivos em 21% a 25%, resultando em um uso reduzido da largura de banda e tempos de carregamento melhores.
Redes de fornecimento de conteúdo (CDNs)
Seleção dinâmica de CDN
No Wix, sempre usamos CDNs para exibir todo o código JavaScript e as imagens nos sites dos usuários.
Recentemente, fizemos a integração com uma solução do nosso provedor de DNS para selecionar automaticamente a CDN com a melhor performance de acordo com a rede e a origem do cliente. Isso nos permite veicular os arquivos estáticos do melhor local para cada visitante e evitar problemas de disponibilidade em um determinado CDN.
Em breve: domínios de usuários veiculados por CDNs
A última peça do quebra-cabeça é servir a última e mais importante parte, por meio de um CDN: o HTML do domínio do usuário.
Como 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. Manter essa solução em tantas novas regiões também tem custos operacionais, e adicionar novos locais se torna um processo que precisamos gerenciar e otimizar continuamente.
No momento, estamos nos integrando a vários provedores de CDN para oferecer todo o site do Wix diretamente dos locais de CDN e melhorar a distribuição dos nossos servidores em todo o mundo, melhorando ainda mais os tempos de resposta. Isso é um desafio devido à grande quantidade de domínios que oferecemos, que exigem terminação SSL na borda.
A integração com CDNs aproxima os sites do Wix dos clientes e traz mais melhorias na experiência de carregamento, incluindo tecnologias mais recentes, como o HTTP/3, sem esforço extra do nosso lado.
Algumas palavras sobre o monitoramento de desempenho
Se você tem um site do Wix, provavelmente está se perguntando como isso se traduz nos resultados de desempenho do seu site do Wix e como nos comparamos com outras plataformas de sites.
A maior parte do trabalho acima foi implantado no ano passado, e parte dele ainda está sendo lançada.
O Web Almanac do HTTPArchive publicou recentemente a edição de 2020, que inclui um excelente capítulo sobre experiência do usuário do CMS. Muitos dos números descritos neste artigo são de meados de 2020.
Esperamos receber o relatório atualizado em 2021 e estamos monitorando ativamente os relatórios do CrUX dos nossos sites e as métricas de performance internas.
Temos o compromisso de melhorar continuamente os tempos de carregamento e oferecer aos nossos usuários uma plataforma em que eles possam criar sites como imaginam, sem comprometer a performance.
Recentemente, a DebugBear lançou uma análise de desempenho do criador de sites muito interessante, que aborda algumas das áreas mencionadas acima e examina o desempenho de sites muito simples criados em cada plataforma. Esse site foi criado há quase dois anos e não foi modificado desde então, mas a plataforma está sempre melhorando, e a performance do site também, o que pode ser observado ao acessar os dados do último ano e meio.
Conclusão
Esperamos que nossa experiência inspire você a adotar uma cultura orientada para a performance na sua organização e que os detalhes acima sejam úteis e aplicáveis à sua plataforma ou site.
Para resumir:
- Escolha um conjunto de métricas que você possa acompanhar de forma consistente usando ferramentas recomendadas pelo setor. Recomendamos as Core Web Vitals.
- Use o armazenamento em cache do navegador e 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 e compartilhar ideias no Twitter e no GitHub e participar da conversa sobre a performance da Web nos seus canais favoritos.