Saiba tudo sobre Core Web Vitals nesta uma hora de webinar apresentado por Dan Shappir, Diretor de desempenho tecnológico no Wix.com, e Dikla Cohen, Consultora de ecossistema web no Google. Descubra como o Wix se preparou para a nova experiência de página do Google e obtenha orientações de especialistas sobre a otimização do desempenho do seu site para assegurar uma excelente experiência do usuário.
Transcrição: Entendendo o alto desempenho do Wix e pontuação CWV
Oradores
Dikla Cohen, Consultora de ecossistema web, Google
Brett Haralson, Gerente de comunidade, Wix
Dan Shappir, Diretor em desempenho tecnológico, Wix
00:02
Brett: Oi, gente. Bem-vindos. Sejam todos bem-vindos ao webinar sobre desempenho do Wix. Sou o anfitrião, Brett Harralson. Adianto que vem aí uma apresentação repleta de conteúdo para vocês, temos convidados fantásticos. Hoje vamos falar sobre otimização para Core Web Vitals, vai ser incrível. Vou apresentar nossos convidados rapidinho e começamos. Primeiro, temos a incrível Dikla que trabalha no Google como Consultora de ecossistema web. Ela oferece apoio aos principais parceiros do Google, ajudando-os a alcançar experiências de usuário exemplares e velocidade de crescimento de negócios através da alavancagem de tecnologias de ponta e, é claro, dos recursos web mais recentes do Chrome. Dikla, estou muito feliz com a sua presença, obrigada por vir.
E diretamente do Wix, temos o Dan, a maioria da comunidade de Parceiros já o conhece. Ele lê e responde a muitas de suas perguntas bem técnicas e se concentra na otimização de sites aqui, especialmente para velocidade. A maioria de vocês já conhece o Dan, ele é o cara. Estou muito feliz de ter vocês aqui. Isso é muito legal.
Vamos fazer assim: a Dikla começa nos falando sobre Core Web Vitals, então, trocamos, e o Dan fala especificamente sobre o que faz para priorizar o desempenho do Wix, além de mitos sobre desempenho e as melhores práticas para alcançá-lo. Então, vamos começar. Dikla, seja bem-vinda. Se quiser, pode começar a falar sobre Core Web Vitals.
01:38
Dikla: Obrigada, Brett. Olá, pessoal. É ótimo estar com vocês. Obrigada pela introdução, Brett. Eu sou a Dikla, sou Consultora de ecossistema web no Google e vou falar um pouco sobre Core Web Vitals para vocês. Portanto, antes de nos aprofundarmos, vamos falar sobre qual a essência vital do Core Web Vitals. Desculpe o trocadilho. O principal é a experiência do usuário, claro. E isso é algo que nem sempre é fácil de mensurar. Consideramos três os pilares da experiência do usuário que são bem distintos entre si. O primeiro é o carregamento da página. Quando algo deve acontecer, acontece de fato? Vejo na página o que eu quero ver? Depois temos a interatividade. Essa página é responsiva? Está respondendo em um tempo adequado? Essa resposta deve acontecer o mais rápido possível, claro. E, por último, a estabilidade visual. É agradável visualizar essa página? Ou as coisas ficam se movendo? E aí por diante.
Como mencionei, não é uma tarefa fácil. Para isso, criamos os Core Web Vitals e os definimos com três métricas. Tempo de renderização de maior conteúdo (LCP), Primeiro atraso de entrada (FID) e, por último, Mudança de layout cumulativa (CLS). É possível ver os diferentes limiares aqui. Um bom valor mínimo para as métricas é 75% de carregamento de páginas, pois assegura que você esteja satisfazendo a maioria de seus usuários.
Talvez você tenha tomado conhecimento sobre os Core Web Vitals. O Google Search Console os anunciou como um novo sinal, que combina os sinais corporativos com nossos sinais existentes que são vitais para a experiência da página, o qual ainda vai ser lançado. Na verdade, o lançamento já começou. Está sendo gradual, começou no meio de julho e vai continuar até o fim de agosto.
Vamos falar sobre cada métrica. O LCP mensura o tempo de renderização do maior elemento de conteúdo, seja imagem ou texto. Se olharmos ao canto superior direito, por exemplo, a avaliação continua até que o usuário interaja com a página. Isso se dá, normalmente, a partir da visualização inicial da página. No começo, reconhecemos apenas um pouco do texto, pois é o que há na página. Eventualmente, quando a página termina de carregar, o que vai ser reconhecido como a impressão do maior conteúdo é a imagem ali. Portanto, o tempo que demora para a imagem ser carregada vai ser contabilizado como impressão do maior conteúdo.
Em seguida, o FID mensura o tempo gasto a partir do momento em que usuário faz sua primeira interação com a página até o navegador conseguir responder, de fato, a essa interação. Todo mundo já passou por uma situação na qual você interage com a página e nada acontece, demora um tempo. Claro que essa não é uma boa experiência do usuário. Portanto, aqui é analisado o tempo levado para que o navegador consiga responder à primeira interação do usuário.
E, finalmente, o CLS é a soma do conjunto de mudanças inesperadas ocorridas na página que, claro, não proporcionam uma experiência do usuário agradável. Então, aqui são contabilizadas situações em que estamos em um site e um botão, imagem ou anúncio aparece modificando o conteúdo da página, em um limite máximo de cinco segundos. Se quiser saber mais, visite os diferentes links do web.dev compartilhados aqui. Lá você pode conhecer todos os recursos que temos e saber mais sobre cada métrica.
Há diferentes ferramentas para mensurar os Core Web Vitals, algumas das quais vocês podem estar familiarizados ou não. Temos o Lighthouse, o CrUX (Relatório de experiência do usuário do Chrome) e o PageSpeed Insights, que de certa forma é uma combinação destes dois. Além do Google Search Console, há as Ferramentas para desenvolvedores e a extensão Web Vitals do Chrome, dentre outras. Cada uma delas oferece um valor diferente a fim de otimizar a sua experiência do usuário.
E, finalmente, o CLS é a soma do conjunto de mudanças inesperadas ocorridas na página que, claro, não proporcionam uma boa experiência do usuário. Então, aqui são contabilizadas situações em que estamos em um site e um botão, imagem ou anúncio aparece modificando o conteúdo da página, em um limite máximo de cinco segundos. Se quiser saber mais, visite os diferentes links do web.dev compartilhados aqui. Lá você pode conhecer todos os recursos que temos e saber mais sobre cada métrica.
Há diferentes ferramentas para mensurar os Core Web Vitals, algumas das quais vocês podem estar familiarizados ou não. Temos o Lighthouse, o CrUX (Relatório de experiência do usuário do Chrome) e o PageSpeed Insights, que de certa forma é uma combinação destes dois. Além do Google Search Console, as Ferramentas para desenvolvedores e a extensão Web Vitals do Chrome, dentre outras. Cada uma delas oferece um valor diferente a fim de otimizar a sua experiência do usuário.
06:32
Dikla: Vale notar que alguns deles exibem dados de laboratório, outros exibem dados de campo e outros, ainda, exibem ambos. Os dados de laboratório são dados mensurados em um ambiente específico durante o carregamento da página e demonstram o que os usuários normalmente experienciam nesse ambiente. São ótimos para resolução de bugs e para, por exemplo, quando você quer implementar uma mudança de UI e saber como seu desempenho vai ser impactado, pois você pode comparar os dados de laboratório de antes e depois a partir do feedback imediato que receber.
Por outro lado, os dados de campo, também conhecidos como métricas de usuários reais, são dados coletados em experiências de campo reais com usuários reais visitando seu site. Tais dados podem ser coletados por você mesmo. O Google, além de também coletá-los, compartilha eles publicamente a partir do CrUX, o Relatório de experiência do usuário do Chrome. A coleta é feita de forma anônima com usuários voluntários e mostra qual experiência obtêm no seu site. Os dados de campo são o ponto principal que devem ser observados na avaliação da experiência de seu site.
Sei que vocês provavelmente têm perguntas e muitas outras vão surgir quanto mais souberem sobre Core Web Vitals. Visitem todos os links do web.dev e recursos que foram compartilhados, como mencionei antes, além do FAQ do Core Web Vitals, que é um ótimo lugar para saber mais. A primeira pergunta é, surpreendentemente, de onde vêm os dados corporativos que a busca considera como sinais vitais? Eles vêm do CrUX. Você pode usar o Relatório de experiência na página do Google Search Console para dados de usuários reais e para entender um pouco mais, pois, como eu disse, cada ferramenta é um pouquinho diferente. O Relatório de experiência do usuário permite a análise de grupos de URLs que são separados de acordo com o tipo da página. É muito útil.
E, por último, quero mencionar o Wix e os ótimos investimentos e progressos que obteve em desempenho geral com os Core Web Vitals especificamente. Seja evoluindo a infraestrutura, como vemos neste belo estudo de caso publicado recentemente, seja tornando os dados de desempenho mais acessíveis aos usuários através da criação do painel de controle de velocidade do site para os Parceiros Wix. O Dan vai falar disso daqui a pouco. Como resultado desses investimentos, vimos grandes melhorias nos Core Web Vitals no decorrer do último ano. O número de origens do relatório com bons Core Web Vitals aumentou significantemente para os sites Wix. Você pode verificá-los no novo relatório Core Web Vitals Technology Report. Espero que continue subindo. Sei que vai. O Dan vai falar mais sobre isso. Eu finalizo por aqui. Muito obrigada. E, Brett, é com você.
10:20
Brett: Obrigado. Muito obrigado pela sua apresentação, Dikla. Estou bem animado para que o Dan conte o que o Wix tem feito. Antes de prosseguirmos, quero perguntar algumas coisas. Para deixar ainda mais claro, como é determinado se uma página passa ou reprova na avaliação de Core Web Vitals?
10:43
Dikla: Certo. Isso é calculado com 75% do carregamento de páginas durante 28 dias, a partir do CrUX, portanto uma página precisa atingir todos os três Core Web Vitals para passar na avaliação.
11:04
Brett: Obrigado. Sei que há várias outras perguntas e vou tentar trazê-las no final, mas eu tenho mais duas perguntas importantes para mim. Você falou um pouco sobre ferramentas de velocidade de site e mensuração, como Lighthouse e PageSpeed Insights. Já vi isso algumas vezes em algumas conversas de nossos parceiros, e eles discutiam sobre a diferença nos resultados variáveis entre algumas dessas ferramentas. Você pode nos falar um pouco sobre por que isso acontece?
11:38
Dikla: Sim, essa é uma ótima pergunta. Cada ferramenta é diferente, certo? E há várias coisas que podem influenciar os resultados que você vê. A primeira, claro, são os dados de laboratório vs. dados de campo, que mencionamos, certo? Essa é a principal coisa que pode criar essa discrepância, pois os dados de laboratório são coletados em um ambiente muito específico, enquanto que os dados de campo são de todos seus usuários.
Porém, mesmo que você esteja olhando apenas para dados de laboratório, você pode ter alguns resultados diferentes. Às vezes podem acontecer por ocorrerem em um ambiente diferente, certo? Então, a depender se você estiver rodando o Lighhouse no PageSpeed Insights ou nas Ferramentas para desenvolvedores do Chrome, você vai receber resultados bem diferentes, pois são ambientes diferentes. Além disso, se rodá-lo em seu próprio computador, você vai ver como a página é exibida atualmente, mas se rodá-lo no PageSpeed Insights vai ver como é exibida para usuário anônimo pela primeira vez.
Já os dados de campo, ainda que possam vir do CrUX, podem ser diferentes se a análise for sobre todos os dados de origem disponibilizados no Relatório de experiência do usuário do Chrome e por mês. No PageSpeed Insight podem haver tanto os dados de origem quanto os específicos da página. Além disso, são analisados no período dos últimos 28 dias, ao invés de um mês. E, então, temos o Relatório de experiência na página do Google Search Console que mostra grupos separados por tipos de páginas. No fim, cada uma dessas ferramentas oferece algo diferente e possui diferentes insights e, dessa forma, o resultado pode variar.
13:32
Brett: Muito obrigado, isso faz muito sentido e acho que respondeu a várias perguntas aqui. Então, obrigado. Vou fazer só mais uma e passamos a palavra para o Dan dizer como o Wix tem se otimizado. Desde que o Core Web Vitals foi lançado, vimos mudanças e atualizações nas métricas e eu gostaria de saber se isso vai continuar acontecendo.
13:54
Dikla: Sim. Então, o Core Web Vitals foi feito para ser dinâmico, pois, como mencionei aqui, mensurar a experiência do usuário é um desafio. Se desejamos melhorá-la e sermos melhores nela, às vezes isso significa modificar as métricas. Essas mudanças sempre foram comunicadas e vão continuar sendo para que os usuários possam se preparar e, assim espero, ficar cada vez melhores.
14:33
Brett: Muito obrigado, Dikla. É uma honra ter você com a gente e provavelmente vamos ter mais perguntas no final, mas, antes disso, vamos seguir com o Dan. Dan, você é um cara ocupado. Conte um pouco para a gente o que você tem feito para priorizar o desempenho do Wix.
14:54
Dan: Obrigado, Brett e Dikla. Recebemos muita informação valiosa. Oi, pessoal. Bom, como vimos na apresentação da Dikla, ter um bom desempenho, um bom engajamento, uma taxa de rejeição baixa para o site e aplicar o SEO são coisas muito importantes para o sucesso de um site. Como resultado, no Wix, estamos investindo esforços significativos e recursos para melhorar o desempenho de todos os sites hospedados na nossa plataforma.
De fato, a melhora de desempenho é a maior prioridade dentro do Wix e envolve cada parte da nossa organização. E, como resultado disso, muitos de vocês notaram melhorias de desempenho em seus sites, sem que precisassem fazer algo. Dito isso, é importante enfatizar que diferentes sites Wix experienciam diferentes níveis de melhora. Eu diria que a melhora de desempenho é uma jornada, não apenas um destino, portanto sempre há trabalho a ser feito. Alguns aspectos da nossa oferta estão mais adiantados que outros, mas estamos trabalhando duro para que se igualem.
Um ótimo exemplo do esforço que temos feito é que rearquitetamos e reescrevemos muitos dos componentes de visualização da nossa plataforma. A visualização é a coisa ou aspecto da nossa plataforma que pega os dados dos nossos servidores e os usa para renderizar os sites, o HTML e o CSS que você vê quando os visita. O que temos feito é mover boa parte da computação do código que costumava rodar no navegador para nossos servidores mais velozes. Isso teve dois grandes impactos.
Primeiro, reduziu em mais de 80% a quantidade de JavaScript que precisávamos baixar para os navegadores. E, em segundo lugar, descartou muito do esforço computacional que é importante para os visitantes que usam dispositivos mobile low-end. Isso é significativo, pois esses dispositivos têm se tornado o modo mais comum de acessar a web.
Outra coisa na qual investimos muito esforço e recursos é a nossa infraestrutura. Criamos e estruturamos mais centrais de dados no mundo todo, agora temos vários deles. Então, sempre que precisar de um dos nossos servidores, vai ter o que está mais próximo de você. Portanto, é necessário menos hops para obtermos respostas mais rápidas. E, como um benefício adicional, isso também significa melhor funcionamento para o Wix, pois temos mais centrais de dados através das quais compartilhar.
Sabemos muito melhor como utilizar nossas Redes de Distribuição de Conteúdo (CDN). Todos os recursos estáticos que são usados nos sites Wix são entregues através de CDNs, que consiste em uma rede de servidores ao redor do mundo que armazena solicitações e responde rapidamente. Isso é possível, pois estão muito perto dos seus visitantes reais onde quer que estejam. Então, todos esses recursos estáticos, incluindo as mídias, as imagens, os vídeos, os scripts, o CSS etc, além da maior parte do nosso HTML, como mencionei, agora são entregues a partir de CDNs.
E, por último, mas não menos importante, aprimoramos nossos processos para promover o desempenho. Com isso quero dizer que não basta implementar todas essas melhorias para assegurar que o desempenho aumente, também é preciso monitorar constantemente para se certificar de que este desempenho não abaixe ou retroceda. A solução que encontramos foi organizar os processos e implementar verificações para cada modificação que for feita no nosso código.
19:25
Dan: Há um processo automatizado que faz um teste de desempenho nessa modificação e a compara com o resultado atual. Portanto, se houver uma queda no desempenho, o processo pára e a modificação é cancelada. Além disso, assim como o Google monitora as sessões e coleta os dados para a base de dados deles da CrUX, também monitoramos todas as sessões do Wix, claro, de forma anônima. Fazemos isso a partir de todos os navegadores da web, não apenas do Chrome, e esses dados são atualizados em nossos próprios servidores, nos permitindo monitorar o desempenho o tempo todo. Portanto, se houver, de alguma forma, uma queda, se algo tiver encontrado uma brecha e escapado, vamos saber rapidamente e resolver a situação antes mesmo que alguém, um de vocês, possa notar. Então, essas foram todas as coisas que fizemos no Wix para assegurar que possamos oferecer o melhor desempenho que pudermos.
20:30
Brett: Dan, queria apontar uma coisa rapidinho. Você e o Wix estão ganhando muitos elogios aqui e eu soube dos Parceiros Wix que, nas últimas semanas, eles notaram incríveis melhorias de velocidade. Você tem fãs aqui presentes. A Lauren, por exemplo, está dizendo que a pontuação dela em desktops está quase perfeita. Muitas pessoas estão felizes com isso, pois realmente virou o jogo para eles em relação a velocidade. Então, eu queria apenas repassar isso. Um enorme obrigado ao Wix, vocês são demais. E vocês tem alguns fãs.
21:06
Dan: Muito obrigado, Brett, fico muito feliz em saber. Primeiro, continue recebendo as respostas, tanto as boas como as ruins. Pode ser que vocês ainda encontrem problemas de desempenho. Como eu disse, sua pontuação pode variar dependendo de nossos componentes. Estamos fazendo muitos avanços, mas não é possível fazê-los todos ao mesmo tempo.
Além disso, as escolhas que você faz tem um impacto no desempenho do seu site. Vamos falar disso mais adiante. Antes disso… A Dikla já mostrou um gráfico semelhante a esse, basicamente retirado do HTTP Archive, que se baseia e utiliza os dados do CrUX e consiste em uma ferramenta do Google. Uma ferramenta patrocinadora do Google, na verdade.
Ela mostra os dados de desempenho que o Google coleta a partir de suas sessões para os sites Wix e para sessões de informações de outros CMSs. Nós somos a linha azul clara e, como podem ver, desde o ano passado crescemos cinco vezes na relação de sessões que são consideradas como boas ou verdes para todos os Core Web Vitals. Portanto, cinco vezes mais sessões, sessões Wix em páginas Wix. Na verdade, os URLs do Wix agora são considerados como bons nas três métricas CLS, LCP e FID para o percentual de 75% do Core Web Vitals. Isso nos assegura, de acordo com o que foi dito pelo Google, o maior impulso possível na classificação. Porém, ainda mais importante, no meu ponto de vista, isso proporciona uma experiência melhor para as pessoas que visitam esses sites.
Agora, antes de falarmos o que você pode fazer para melhorar o desempenho do seu site e obter maiores vantagens de todas as melhorias que estamos fazendo, quero falar sobre alguns mitos e equívocos com os quais me deparo quando converso sobre desempenho no Wix com vários Parceiros, clientes, designers etc.
Então, o primeiro mito é que você não pode melhorar o desempenho de um site Wix e que apenas o Wix pode fazer isso e, portanto, você está em um beco sem saída. A verdade é que as decisões que você toma enquanto projeta e produz conteúdo para seu site impactam significativamente seu desempenho. Como sabem, o Wix é uma plataforma bem flexível, você tem liberdade quase infinita em termos de estrutura e conteúdo para seu site, então as decisões que você toma definitivamente impactam seu desempenho.
O próximo mito que eu quero falar é um que infelizmente vejo muito e, inclusive, o vi recentemente. O mito consiste na suposta necessidade de otimizar as imagens antes de fazer o upload delas no Wix. Por exemplo, recentemente, vi que alguém escreveu que é necessário redimensionar as imagens, a largura e a altura, para que fiquem o menor possível e correspondam exatamente ao tamanho que você gostaria de utilizá-las na sua página.
Isso está totalmente errado e, inclusive, é o contrário. Nós otimizamos as imagens automaticamente e fazemos isso muito bem. Trabalhamos duro para assegurar que entreguemos a quantidade mínima de informações, mas forneçamos a melhor experiência possível a seus visitantes. Então, voltando ao exemplo do redimensionamento de imagens, você deve fazer o upload da maior imagem que tiver em termos de largura e altura. Portanto, nós automaticamente a redimensionamos em nossos servidores, deixando-a no tamanho necessário para a sessão em particular, e baixamos apenas os bits, os pixels que são realmente necessários para a sessão. Dessa forma, você tem o melhor uso dos dados e, ao mesmo tempo, fornece a melhor qualidade de imagem. Outro exemplo é que automaticamente transformamos o formato da imagem em WebP, que é um novo, relativamente novo, formato de imagem originalmente do Google e que agora é suportado pela maioria dos navegadores.
25:53
Dan: Verificamos se o navegador o suporta e, caso afirmativo, entregamos a imagem usando esse formato, pois reduz o tamanho do download da imagem em cerca de 20%. Há uma diferença entre escolher JPEGs e PNGs, mas vou tocar nesse assunto mais tarde.
Outro mito que vejo é que as animações são ruins para seu desempenho e que, se estiver baixo, você deve retirá-las do seu site. Mais uma vez, não é verdade. Se você tiver, por exemplo, parallax no site, o seu desempenho não vai ser impactado em nada. A única coisa para a qual você deve se atentar é o uso excessivo de animações que revelam algo. Se o material que há na visualização inicial é automaticamente animado quando alguém visita seu site, o cabeçalho sai da direita e não podemos dizer que a página terminou de carregar até que esse movimento do cabeçalho termine, pois o visitante não consegue ler o conteúdo até que a animação termine. Portanto, leve em consideração isso se tiver muita animação que relevem coisas automaticamente quando a página carrega, pois você está aumentando seu tempo de carregamento.
E, por último, o último ponto que quero tocar é sobre vídeos grandes impactarem de forma ruim o desempenho. Esse não é o caso de vídeos transmitidos ao vivo pela rede que são entregues de forma muito eficiente na rede e começam a tocar assim que carregam um pouco. Como quando você assiste a vídeos no YouTube, sabe? Não é necessário baixar o vídeo completo para assisti-lo, portanto, é eficiente nesse sentido e, na maioria dos casos, não vai provocar impacto negativo no seu desempenho.
Agora, podemos ir para o ponto principal da minha apresentação. O que você pode fazer para tirar o máximo proveito do seu site Wix em termos de desempenho e Core Web Vitals. Então, vou começar com a coisa mais simples, tipo o componente básico de todo Wix. Aliás, de todo site, não apenas do Wix, mas de todos, sério. O texto. Sabe, o texto é a essência do site, pois é o que diz ao seu visitante quem você é, sobre o que se trata seu site, o que ele pode fazer em seu site etc. Há algumas coisas que podem ser feitas no texto para assegurar um bom desempenho.
Antes de mais nada, certifique-se de que você tenha conteúdo de texto significativo na janela de visualização inicial, também conhecido como acima da dobra, que consiste na área inicial que é visível ao visitante antes de rolar a página para baixo. Eu já vi páginas que têm apenas uma imagem ou talvez até galeria nessa área e até que o visitante role a página para baixo, não há nada para ser lido. E isso, na minha visão, causa uma experiência ruim.
Pois, primeiro, textos carregam mais rápido que imagens e, além disso, quero saber quem você é antes de decidir se quero rolar a página ou não.
Também recomendamos que você limite o número de fontes e pesos de fonte para o site, pois, ao meu ver, o uso excessivo de fontes podem passar uma imagem pouco profissional e pouco atraente. Além disso, em alguns casos, alguns textos podem não ser visíveis até que a fonte usada seja baixada. Portanto, se você estiver usando muitas fontes, vai demorar mais para que sejam baixadas e para que o texto apareça.
Algo que é muito específico do Wix é que há um recurso para fazer o upload de sua própria fonte personalizada. Já vimos situações em que as pessoas por acidente fazem vários uploads da mesma fonte e usam todos eles, ainda que sejam iguais. Isso resulta nessa fonte sendo baixada mais de uma vez pelo navegador do visitante, algo que não é bom para o desempenho. Estamos trabalhando em uma solução sistemática que previna automaticamente que isso aconteça, mas atente-se a isso e evite fazer o upload da mesma fonte mais de uma vez para o mesmo site, até terminarmos a implementação.
30:50
Dan: E outra coisa importante, que até pode parecer não ter relação com desempenho, é assegurar um bom contraste com seu texto. Vou dar um exemplo rapidinho. Vamos supor que você tenha um texto em branco em cima de uma imagem escura que está por cima de um background branco. Bom, acontece que mesmo que o texto carregue antes da imagem, o visitante não vai ver o texto até que a imagem carregue, pois vai ser um texto em branco sobre um background branco. Nós nos esforçamos para que essas imagens sejam carregadas rapidamente, mas o texto normalmente carrega mais rápido, como eu disse antes. Então, tente pensar em como garantir um bom contraste em todas as condições.
E, por último, mas não menos importante, evite textos nas imagens. Não estou me referindo ao texto sobreposto às imagens, não há problema nisso. Estou falando de texto que realmente faz parte da própria imagem, que está embutido na imagem. Isso é ruim para o desempenho, pois até que a imagem seja carregada não há texto. Além disso, também é ruim em termos de SEO e acessibilidade, uma vez que os bots e os leitores de tela não conseguem ver esse texto. Então, sim, é algo ruim e você deve se esforçar para evitar isso.
As mídias, ou seja, as imagens, os vídeos e afins são outra coisa importante em sites modernos. Então, tenha cuidado com download grandes demais, principalmente de imagens. Sabe, se o arquivo de uma imagem tem dezenas ou centenas de kilobytes, é uma coisa, mas se ele tem um par de megabytes, aí já é outra. Não estou falando do tamanho da imagem que você faz upload no Wix, mas do tamanho da imagem que realmente é baixada. Há inúmeras ferramentas que você pode usar para verificar isso, como as Ferramentas para desenvolvedores do Chrome, que são colocadas no navegador, o Network ou a ferramenta Web Page Test etc. Se o seu site tiver arquivos muito grandes para baixar, pode ser prejudicial ao desempenho.
Mencionei antes que otimizamos as imagens para vocês. Não quero me adentrar em detalhes técnicos, pois não temos tempo suficiente para isso, mas prefira JPEGs em vez de PNGs sempre que possível. Normalmente, isso resulta em downloads menores para o mesmo tamanho e quase a mesma qualidade de imagens. Normalmente não há diferenças. Há certas opções para quando PNGs são necessários. Por exemplo, se precisar de transparência ao usar parallax ou algo do tipo, nesses casos, você vai optar pelo PNG. Porém, quando puder escolher, escolha o JPEG. Como eu disse, o tamanho da imagem, o tamanho do download da imagem vai ser menor e seus usuários ou visitantes não vão ver a diferença.
O formato SVG, ou formas, como são referidas no nosso Editor, é melhor do que ambos. Então, por exemplo, se puder colocar seu logo em formato SVG, se estiver usando o Criador de Logo Wix, então opte por usar um SVG. O SVG é menor, é nítido quando criado, se mantém nítido quando o visitante aumenta ou diminui o zoom e é sempre nítido. E, como eu disse, costuma ser menor que qualquer outro formato de imagem.
Procurem evitar os GIFs. Sabe, há certos casos que tudo bem. Por exemplo, se for uma coisinha animada bem pequena, como uma seta apontando para baixo. Porém tome cuidado com downloads muito grandes, você ficaria surpreso. Então, se estiver criando algum tipo de efeito de animação, evite os GIFs, use um vídeo em looping. Basta colocá-lo para rodar em loop e usá-lo no lugar dos GIFs. Eu já vi sites que baixam um GIF de 12 megabytes. Isso é algo ruim para o desempenho. Então, na maioria dos casos, procure evitá-los.
35:20
Dan: Outra coisa específica do Wix é que quando você define uma imagem como background, é possível especificar a cor de background por trás da faixa, atrás da imagem. Se você deixar a imagem um pouco transparente, essa cor aparece através dela. Porém, mesmo que não o faça, essa cor vai ter um valor que pode ser configurado clicando na dobrinha localizada no canto superior esquerdo. Essa cor vai aparecer brevemente, enquanto a imagem carrega, especialmente em conexões mais lentas. Portanto, combine a cor principal da imagem com o background da imagem para uma melhor experiência do visitante. Eu já vi situações onde a cor principal era verde, mas alguém especificou a cor de background como rosa, criando uma transição realmente excêntrica. Isso também pode ter um impacto negativo no seu desempenho.
Quero falar sobre mobile, pois baseado nos dados que coletamos, cerca de 70% das pessoas que visitam os sites Wix usam dispositivos mobiles. Portanto, é muito importante que tenhamos um bom desempenho para mobiles. Então, se você estiver usando o Editor, o Editor Wix, não se esqueça de verificar como suas páginas estão sendo exibidas na versão mobile. Trabalhamos duro para a criação automática da visualização em mobile. Mas você quem sabe, o site é seu. Então, vá no Editor Mobile, certifique-se que tudo está organizado certinho e que seu site tem uma boa exibição para dispositivos mobiles. Uma das coisas legais sobre o Editor Mobile é que você pode tanto esconder quanto adicionar conteúdo especificamente para o mobile. Então, é possível esconder algumas coisas que você só quer exibir na área de trabalho, algo menos importante. O que podemos fazer? O mobile tem menos espaço de tela, então você precisa ser específico. Também é possível adicionar coisas. Então, por exemplo, você pode esconder um conteúdo menos importante, aumentar o mais importante e deixar mais fácil a visualização nessas telas menores.
Também é possível diminuir os itens em galerias, feeds ou repetições. Eu já vi páginas mobiles com 30 telas. Sabe, quem espera que um visitante role por essas 30 telas em um dispositivo mobile? É provável que ela seja longa demais.
Além disso, nada é de graça, quanto mais você coloca coisas na página… Sabe, tentamos melhorar carregamentos lentos para aprimorá-los, mas nada é de graça. Tudo que você coloca na página tem um certo custo. Isso entrou no slide errado sem querer. Vamos cuidar disso. Então, era isso que eu queria dizer sobre mobiles.
Em geral, essas são as sugestões que eu queria fazer. A Dikla mostrou uma captura de tela do nosso novo painel de controle de velocidade do site. Estamos muito felizes que este painel tenha sido mostrado em um Keynote recente do Google I/O. É uma ferramenta muito útil e possui duas partes. Na parte superior, é possível ver os dados de campo que coletamos a partir de sessões reais do site Wix, sessões ao vivo, e que os comparamos com outros sites dentro de seu domínio. Já na parte inferior, é possível ver os dados que recuperamos a partir do Google PageSpeed Insights, portanto essencialmente são os mesmos dados de laboratório que você veria se o rodasse no mesmo site.
39:56
Dan: Se estiver usando o Velo nas suas páginas, especialmente se colocar um script no site que vai impactar todas as páginas, então você vai precisar ativar o cache manualmente para suas páginas. Para isso, vá em Configurações, em Configurações avançadas e, então, habilite a página para ser armazenada em cache e selecione a frequência que seja melhor para você. Isso assegura que o HTML da página seja armazenado em cache no CDN para um carregamento mais rápido.
Se você não usar o Velo, na maioria dos casos, podemos fazer isso automaticamente para você. Porém, se usar, não podemos ver o que acontece com seu código Velo no servidor. Não sabemos se podemos armazenar seu conteúdo em cache com segurança e nem por quanto tempo, por isso é preciso ativá-lo manualmente. Inclusive, quando um conteúdo é armazenado em cache no CDN, você não precisa se preocupar sobre a entrega de conteúdo obsoleto. Por exemplo, se você publicar uma nova versão do seu site, automaticamente atualizamos o CDN para substituir a versão anterior.
Cuidado com o uso excessivo de integrações de marketing como Pixel do Facebook ou Gerenciador de tags do Google. Claro que elas são importantes e possuem um propósito para uma campanha, por exemplo. Porém certifique-se de adicionar apenas as que realmente for usar e de removê-las quando terminar. É fácil esquecê-las, pois as páginas continuam funcionando normalmente, mas possuem um impacto ruim no desempenho. Já vimos páginas do Wix que somente as integrações de marketing contabilizavam a metade do tempo de carregamento da página. Isso é muito.
Em geral, se for usar vídeos, opte pelo player do Wix Video ao invés de players externos, pois nesse caso precisaríamos baixar os vídeos. Por exemplo, o reprodutor de vídeo do YouTube é algo como meio megabyte de um download de JavaScript. Apenas o reprodutor, não o vídeo, isso é muito. Então, em geral, quando puder, escolha o player do Wix Video ao invés de outros reprodutores.
Eu já mencionei isso antes, mas nada é de graça. Quanto mais coisas você colocar em uma página, mais pesada vai ser e mais tempo vai demorar para carregar. Então, se você tiver páginas muito longas, considere dividi-las em páginas menores. Por exemplo, talvez você possa mover as Perguntas e respostas da página principal. Você pode também mover o blog, colocá-lo em outra página e deixar apenas o link, ao invés de tê-lo na sua página inicial. Mais uma vez, é uma decisão sua. O conteúdo é seu. Se for necessário que ele esteja lá, deixe. Apenas esteja consciente do custo de tudo que você coloca na sua página.
As janelas e galerias animadas podem ser prejudiciais. A verdade é que o modo pelo qual cada Core Web Vitals é mensurado e a classificação da experiência de página, em geral, podem penalizar você por usar janelas. Pense nisso, seu conteúdo aparece e, então, poucos segundos depois, uma janela aparece. Da perspectiva do Core Web Vitals, sua página ainda não terminou de carregar até que a janela seja exibida. Isso cria um atraso. Além disso, as janelas atrapalham a exibição do seu conteúdo principal, o que não é bom. Então, sim. Se você estiver com uma promoção especial, faz sentido usar janelas. Porém não coloque um conteúdo primário como “sobre mim” em uma janela, coloque-o em uma página própria. E não use janelas e galerias animadas automaticamente, a não ser que tragam um real benefício para sua página ou site.
44:49
Dan: Minha dica final é… É fácil duplicar uma página, ou mesmo o site completo, no Wix. Você pode duplicar seu site, rodá-lo em uma ferramenta de teste de desempenho, comparar a pontuação do seu conteúdo atual e da cópia do site. É possível usar nosso Gerenciador de versões e testes A/B. Na verdade, você não vai conseguir separar os dados de desempenho no teste A/B. Você pode duplicar sua página, usar uma versão por um tempo e ver como a velocidade do site é impactada e, então, usar a outra versão e verificar sua velocidade novamente. Outra opção é usar uma das ferramentas de laboratório para resultados imediatos. Escolha o que for melhor para você.
Acho que vocês perceberam o quanto gosto de falar e entrar em detalhes, mas antes de concluir minha parte, eu gostaria de dizer que vocês podem me seguir no Twitter. Sou bastante ativo lá. Eu faço tweets sobre coisas relacionadas ao Wix e sobre conteúdos relacionados a desempenho. Às vezes tento escrever coisas no Facebook também, então sintam-se à vontade para entrar em contato comigo lá, mas sou mais ativo no Twitter, e vou tentar seguir todos de volta. Então, mandem um oi por lá. E é isso, Brett.
46:20
Brett: Então, Dan, gostaria de dizer muito obrigado. Tivemos muitas perguntas e vou repassar três para você. Muito obrigado. Isso é muito incrível. Adorei que você pôde vir aqui, fazer essa apresentação, falar sobre esses números e mostrar os esforços para melhorar o desempenho que têm sido feitos para o Wix evoluir. Todos temos visto. E é engraçado que nós passamos tempo juntos, conversamos e ficamos animados com as novidades vindo, mas vê-las concretizadas é diferente, sabe? Ter esses números, mostrar os gráficos…
46:55
Dan: Primeiro, seria excelente se essa apresentação pudesse ser disponibilizada. Gostaria de dizer que a maioria das coisas que estão aqui, talvez tudo, está disponível com mais detalhes em artigos na Central de ajuda. Vocês podem encontrá-la através dos links no novo painel de velocidade do site. Todos os nossos usuários podem ir ao painel de velocidade do site, encontrar esses links sobre desempenho na Central de Ajuda e saber mais sobre o que eu falei aqui hoje. Estamos nos esforçando para assegurar que todas as informações estejam disponíveis.
47:33
Brett: Ótimo. Muito, muito obrigado, Dan. Vou fazer algumas perguntas a você. Uma que eu anotei: “o novo painel de controle da velocidade do site está mostrando que o desempenho do seu site está bom, mas vejo uma pontuação baixa na visualização inicial do Google PageSpeed Insights. Por que isso acontece?”
47:57
Dan: Como eu mencionei, o painel de controle da velocidade do site possui duas partes. A superior, que você vê quando inicialmente carrega a página, e a inferior, que você vê quando a rola para baixo. Então, se estiver olhando embaixo, deve haver a mesma pontuação para área de trabalho e mobile, pois os dados vêm do PageSpeed Insights. Os valores obtidos ali vêm da análise do seu site, da sua página e da sua página inicial no PageSpeed Insights.
Agora, como a Dikla mencionou, podem haver flutuações nas suas pontuações, pois a web e a internet não operam no vácuo. Você pode rodar o PageSpeed Insights e o Velocidade do site algumas vezes e ver como as pontuações variam um pouquinho. Mas, em geral, o número na parte inferior deve ser o mesmo.
Já o número superior, os valores que você vê na parte superior, como mencionei, são coletados a partir de campo. Então, são os números que coletamos a partir de sessões com pessoas reais que visitam seu site e que podem ou não corresponder aos do PageSpeed Insights. No PageSpeed Insights, como a Dikla disse, os dados são coletados em um ambiente particular. Esse ambiente pode ser similar ou mesmo muito diferente dos que seus visitantes realmente têm. Se é diferente, então seus usuários podem ter uma experiência melhor ou pior do que a exibida no PageSpeed Insights. Agora, no fim das contas, o que realmente importa é a experiência real dos seus visitantes, como a Dikla mencionou. É isso que conta para o sucesso do seu site em termos de classificação no Google e, ainda mais importante, de engajamento ou rejeição dos visitantes. Quando as pessoas visitam seu site, não se importam com a sua pontuação no PageSpeed Insights, se importam com a experiência que obtêm. Você pode usar sua pontuação no PageSpeed Insights como um indicador. Veja seu cenário atual, faça algumas mudanças e veja se melhorou ou piorou. Baseado nisso, você pode ter uma ideia do que pode acontecer quando você implementá-la em campo. Mas é mais ou menos o valor desses testes de laboratório.
50:46
Brett: Como sempre, Dan. Uma resposta muito completa e precisa.
Dan: E esse é um jeito legal de dizer que sou…
Brett: Muito informativa. Não, não. Muito informativa. Isso é ótimo, temos um painel incrível. Dikla, quero fazer uma pergunta para você. Mais cedo, quando você apresentava, havia uma pequena conversa paralela em que os participantes falavam sobre algumas das extensões para o Core Web Vitals. Acho que o Ryan já a respondeu, mas minha pergunta “há alguma recomendação?”
51:25
Dikla: Bom, há apenas uma oficial do Google, disponível no Google Store, que foi criada pelo Addy Osmani, um engenheiro sênior do Chrome. Acho que podemos compartilhar um link mais tarde junto com a gravação. Vamos fazer isso. Mas, sim, há uma do Chrome. Você pode encontrar mais detalhes sobre ela na página do Google no GitHub.
51:56
Brett: Perfeito. Obrigado. Muito obrigado, Dikla. Dan, tenho outra para você. É o seguinte: “o Google Search Console mostra que algumas páginas minhas têm ‘necessidade de melhorias’ ou mesmo CWV baixo. Como isso vai impactar a classificação na busca?”
52:20
Dan: Pergunte a Dikla, ela também não vai conseguir responder. Olha, no fim das contas, a classificação é com o Google. E o que posso dizer, baseado no que o Google diz, é que o Google classifica primeiro a partir do conteúdo, da autoridade e de coisas do tipo. O conteúdo é o principal, como as pessoas dizem no SEO. E, no fim das contas, o Google quer lhe mostrar coisas que você quer encontrar.
Os Core Web Vitals, como parte dos sinais de experiência da página, são apenas algumas das centenas de sinais que funcionam como entradas para o motor de busca do Google. Então, se estiver em um campo muito competitivo, você pode pensar nisso como um critério de desempate. Se você e seu concorrente tiverem mais ou menos a mesma qualidade de conteúdo, então o sinal de experiência da página pode funcionar como desempate. E, dentro desse cenário, o desempenho pode ser um fator decisivo.
Eu não trabalho para o Google e não sei o que acontece dentro da busca. A informação que posso passar, pois foi dita no Google I/O mais recente, é que o Google olha para cada uma dessas três métricas separadamente. Por exemplo, se você tiver um bom FID e um LCP ruim, você ainda pode ter um impulso na classificação para o FID, mas não para o LCP. Portanto, cada uma delas é tratada de forma independente.
Também disseram que se houver um valor ruim para uma métrica em particular do Core Web Vitals, então você não tem impulso para essa métrica. Se obtiver um “amarelo” ou “Necessita de melhorias”, você vai ter um impulso parcial dependendo de quão perto estiver para a pontuação boa, e uma estabilização de impulso quando atingi-la. Portanto, quando você atingi-la, vai obter o máximo de impulso para essa métrica particular, a qual não vai mais subir.
Mas, como eu disse, do meu ponto de vista, a coisa mais importante é que sites com bom desempenho possuam bons engajamentos. Sabe, se as pessoas entram no seu site, mas saem por conta de mau desempenho, qual o sentido de tudo? É isso que posso dizer.
54:54
Brett: Interessante. E há mais uma pergunta que achei muito boa. “Há alguma pontuação específica no PageSpeed Insights que alguém deve focar para se classificar bem no Google? Há um número, um indicador? O que você recomenda?”
55:12
Dan: A Dikla pode complementar se quiser, mas o PageSpeed Insights por si só não é um sinal de classificação. Como a Dikla mencionou, o que o Google usa como sinal de classificação, que pode impactar a sua no Google, é a experiência real que visitantes reais têm no seu site que são coletadas na base de dados do CrUX, não no PageSpeed Insights. O PageSpeed Insights pode ser um indicador do que você pode esperar. Então, por exemplo, se não houver tráfego suficiente ainda, se não houver publicações, então você não tem nada no CrUX. Só vai haver quando houver tráfego suficiente. Então é possível usar a pontuação de laboratório do PageSpeed Insights como um indicador do que você pode esperar obter.
Em grande parte, eu usaria o PageSpeed Insights como um meio para ver se você está melhorando ou regredindo. Com sua pontuação atual, faça algumas alterações e veja se isso a aumenta. Agora, como essa pontuação vai se relacionar com o que seus usuários realmente experienciam? Não sei. Depende. Se seus usuários são principalmente do Canadá, onde geralmente há conexões mais rápidas e as pessoas costumam usar dispositivos mobiles mais rápidos como iPhones, pode ser que sua pontuação para mobile seja duas ou três vezes melhor do que é exibido no PageSpeed Insights. Quem sabe?
56:50
Brett: Bom, isso faz sentido. Faz muito sentido, Dan. Gostaria de saber da Dikla. Você gostaria de complementar?
56:57
Dikla: Sim, em geral, o que o Dan estava falando é bem verdade e falamos sobre isso mais cedo. Sobre a classificação, não posso comentar. Também não sei dizer. Como o Dan mencionou, o ponto principal aqui é melhorar a experiência do usuário. Isso é algo que definitivamente vale a pena fazer com a análise de ambos os dados, de laboratório e de campo.
57:26
Dan: Eu já disse isso, mas tudo o que dissemos em relação a classificação não é baseado em uma informação privilegiada que o Google nos passou e que ninguém mais sabe. É tudo baseado no meu entendimento de informações públicas que o Google anunciou, por exemplo, na conferência mais recente do Google I/O.
57:49
Brett: Bom, posso dizer que esse webinar foi repleto de informações incríveis e ótimas dicas. Vocês dois são sensacionais. Não sei dizer o quanto fico grato pela presença e pelo compartilhamento dessas informações. Acho que poderíamos fazer isso toda semana, eu voluntario vocês dois. Brincadeira. Mas foi incrível, de verdade. Portanto, quero dizer obrigado. Sei que os Parceiros adoraram hoje e que todos realmente querem que seus sites sejam excelentes, otimizados, encontrados na internet e bem sucedidos. Um enorme obrigado a vocês. Obrigado.
תגובות