- 6 de jul. de 2022

Como otimizar seu site para Core Web Vitals

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.

Leia a transcrição

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.