Desmistificando os Principais Pontos Vitais da Web para WordPress

O Core Web Vitals agora representa um conjunto de métricas obrigatórias para otimizar seu site, principalmente se o SEO e o desempenho do site forem importantes para sua estratégia digital. No entanto, pode ser difícil descobrir quais ferramentas e estratégias do WordPress são mais importantes ao tentar melhorar os Core Web Vitals em seu site.

Assista a esta sessão para obter uma visão aprofundada das melhores práticas e ferramentas para entender e melhorar suas pontuações de Core Web Vitals em seu site WordPress.

Caixas de som:

• Alex Zuniga, gerente de produto da WP Engine
• Mark Davoli, Diretor de Desenvolvimento Web da Amsive Digital
• Matt Chase, diretor de desenvolvimento da Vital Design
• Sanjucta Ghose, Desenvolvedor Web Sênior na WP Engine
• Mike Crantea, diretor de engenharia de front-end da XWP

Transcrição:

ALEX ZUNIGA: Olá, bem-vindo ao Desmistificando os Principais Pontos Vitais da Web para WordPress. Sou Alex Zuniga, gerente de produto aqui na WP Engine. E hoje, vamos realmente discutir os prós e contras dos principais sinais vitais da web para o seu site WordPress. Core Web Vitals é uma métrica obrigatória para otimizar se você se preocupa em otimizar seu site para SEO, para desempenho do site. Mas pode ser difícil saber quais ferramentas e estratégias do WordPress são mais impactantes. Portanto, participe desta sessão para uma análise detalhada de como as melhores práticas e ferramentas podem ajudá-lo a melhorar suas pontuações vitais da Web para WordPress.

Agora, sem mais delongas, vamos apresentar nossos palestrantes para esta sessão. E primeiro, vou passar para Mike para fazer uma breve introdução sobre si mesmo.

MIKE CRANTEA: Olá, sou Mike Crantea. Estou localizado nas Ilhas Canárias Espanha. Sou o diretor de engenharia de front-end da XWP, onde atuei nos últimos 17 anos. Principalmente no espaço de tecnologia de front-end, adoro desempenho na web. E estou feliz por estar aqui. Ei.

ALEX ZUNIGA: Obrigado, Mike. Em seguida, temos Matt Chase.

MATT CHASE: Sou o Diretor de Desenvolvimento da Vital Design em Portsmouth, New Hampshire. Foco de frontend pesado no meu trabalho. Portanto, fazemos muitas pontuações do farol e do Core Web Vital.

ALEX ZUNIGA: Incrível. Obrigado, Matt. E Marcos.

MARK DAVOLI: Olá, sou Mark Davoli, Diretor de Desenvolvimento Web da Amsive Digital. Temos nos especializado no espaço Core Web Vital para nossa equipe, pois SEO é muito importante para nossa empresa. E, portanto, os Core Web Vitals também. Feliz por estar aqui.

ALEX ZUNIGA: Feliz por ter você, cara. E por último, mas não menos importante, Sanjucta.

SANJUCTA GHOSE: Olá. Eu também sou do WP Engine. Faço parte da equipe responsável pela manutenção dos sites da WP Engine. E isso inclui os sites que vieram com o Delicious Brains quando o WP Engine os adquiriu. E passei boa parte do ano passado otimizando os sites Delicious Brain para Core Web Vitals. Então, acho que essa deve ser uma conversa muito interessante. Feliz por estar aqui.

ALEX ZUNIGA: Obrigado. Obrigado. Bem, bem-vindos a todos os nossos palestrantes. E mal podemos esperar para ouvir o que você tem a dizer. Então, vamos dividir essas questões por medição, gerenciamento, ferramentas e expectativas do cliente quando se trata de Core Web Vitals. Então, nossa primeira pergunta que queremos fazer a todos vocês, por que eu deveria me importar com o Core Web Vitals em primeiro lugar? E até que ponto devo me concentrar na otimização do Core Web Vital?

MARK DAVOLI: Posso falar sobre isso, se quiser. Para mim, é muito importante garantir que você tenha uma velocidade de página rápida. E a razão pela qual isso é importante está nas conversões do resultado final. Certo? Portanto, quando alguém acessa um site, quanto mais demora para carregar, mais provável é que ele saia. E se você não tiver uma velocidade de página rápida, ficará sem sorte e perderá muitos negócios potencialmente. Especialmente em uma loja de comércio eletrônico.

SANJUCTA GHOSE: Então, sim. Eu meio que concordo com o que você disse porque, embora seja muito importante para o SEO, também precisamos lembrar que os Core Web Vitals são uma medida do desempenho percebido do seu site. Como o usuário percebe seu site. E acho que é muito importante manter a atenção de que o usuário percebe seu site como responsivo, interativo e estável. Quais são as coisas que o Core Web Vitals mede. Portanto, acho que ainda mais do que as pontuações de SEO, é importante que a percepção do usuário sobre seu desempenho seja importante. E é por isso que devemos focar nos Core Web Vitals.

ALEX ZUNIGA: Com certeza. Matt, você tinha–

MATT CHASE: Sim, basicamente é isso que eu ia dizer, sim, o aspecto de SEO é ótimo. Mas, em última análise, codificamos esses sites para as pessoas. E queremos que essas pessoas tenham o site mais rápido e ágil possível. Mas isso afeta os dois mundos. Certo? Então, nós meio que – quando sintonizamos esses Core Web Vitals, estamos fazendo um ótimo UX. Mas de uma forma que satisfaça as equipes de SEO, o que às vezes nem sempre é uma batalha fácil de vencer. Então funciona para todos.

ALEX ZUNIGA: Então, com tudo isso dito, sabemos que é importante. Mas quais são as melhores maneiras de medir nossa pontuação?

MARK DAVOLI: Então, uma das maneiras de medir além de usar– bem, existe a ferramenta Page Speed ​​Insight do Google, que é crítica porque é a ferramenta que eles usam para medir. Certo, então se você quer causar impacto, usar essa ferramenta é vital. Também existe o Lighthouse no navegador, bem no Chrome DevTools, o que é super importante. E o Search Console tem uma ótima ferramenta de experiência do usuário da página para monitorar as métricas reais do usuário nos últimos 28 dias, o que é crítico para o monitoramento de longo prazo.

SANJUCTA GHOSE: Sim. Então, eu diria que o Page Speed ​​Insights é uma ferramenta muito boa porque fornece dados em tempo real no sentido de que os próprios principais indicadores vitais da Web são baseados em dados reais de usuários nos últimos 28 dias. Mas você também pode ver seu relatório Lighthouse, que é baseado em dados de laboratório. E é nisso que você pode melhorar imediatamente, porque leva algum tempo até que você possa realmente ver as melhorias no Core Web Vitals porque ele é medido ao longo de um período de tempo.

Portanto, se você está tentando melhorar suas pontuações, acho que o Lighthouse é uma ótima ferramenta porque fornece a você– ele informa quais são suas oportunidades de melhorar. Assim, você pode tentar implementar imediatamente essas oportunidades e ver como isso melhora sua pontuação.

ALEX ZUNIGA: Incrível. Parece um grande grito para o Lighthouse lá. Excelente. Excelente.

MIKE CRANTEA: Gostaria de acrescentar a este tópico que o rastreamento de dados reais de desempenho de métricas do usuário foi melhor para poder reagir mais rapidamente às degradações de desempenho que atingiram a produção. Os testes de laboratório ajudam quando você está no estágio. Como dizer que há uma degradação que não queremos propagar. Mas sempre vai acontecer algo na produção que pode ser uma surpresa. E, em vez de esperar várias semanas para que o Search Console e as métricas reais do usuário no banco de dados crux apareçam, ao rastreá-las você mesmo com uma biblioteca do Web Vitals, você pode ficar à frente da curva.

ALEX ZUNIGA: Incrível. Sim. Sempre tenho que ficar à frente dessas surpresas de produção que surgem às vezes. Tudo bem. Bem, obrigado por responder aqueles sobre medição. Agora, olhando para o gerenciamento, quais são uma ou duas coisas que você pode fazer para ter o maior impacto nos Core Web Vitals?

MATT CHASE: Então, acho que uma coisa que me chama a atenção é o carregamento preguiçoso, como tudo o que você puder. E adie o carregamento de tudo o que puder. Isso para mim é o tipo de solução pronta para uso que você pode simplesmente fazer e ver uma melhoria imediata. O WP Rocket tem várias caixas de seleção realmente muito fáceis que você pode ativar para ativar esse tipo de coisa.

MARK DAVOLI: Sim. E para mim, o foco principal é o que chamamos de renderização acima da dobra. Portanto, certifique-se de que seja processado o mais rápido possível. E, como mencionado anteriormente, adiar e carregar lentamente qualquer outra coisa que esteja fora da tela para garantir que você obtenha a melhor pontuação possível. Dito isto, o WP Rocket é excelente para seu recurso de scripts de atraso. Mas tendemos a - como eu tento limitar isso ao GTM, ou scripts de anúncios do Google, ou coisas assim. E realmente concentre-se em melhorar a arquitetura central real do tema que alimenta o site para garantir que seja otimizado o máximo possível. Portanto, você não depende de um plug-in de terceiros para ter esse tipo de impacto no desempenho.

MATT CHASE: Com certeza. Sim. Ambos os finais.

ALEX ZUNIGA: Entendi. Peguei vocês. E só para esclarecer, você disse WP Rocket. E esse é o recurso de scripts de atraso?

MARK DAVOLI: Sim.

ALEX ZUNIGA: Incrível.

MIKE CRANTEA: Uma coisa que não recebe atenção suficiente é o armazenamento em cache. Mas o tempo de resposta rápido do servidor não garante uma experiência rápida. Mas se o seu servidor responder lentamente, você estará garantindo uma experiência lenta. Portanto, fazer uso de todas as camadas de cache disponíveis – cache do navegador, cache de objeto, cache de página – e tê-los ativados e funcionais é um bom primeiro passo. Faça o básico. E então você pode trabalhar para trabalhar até as otimizações de front-end. Verificando o que está em sua cabeça. E assim por diante.

ALEX ZUNIGA: Excelente

SANJUCTA GHOSE: Sim. E acho que também não devemos esquecer de otimizar nossas imagens. Eu acho que é muito importante porque muitos sites hoje em dia tendem a ter muitas imagens. Portanto, acho importante que você comprima suas imagens, sirva-as por meio de um CDN e, como você já mencionou, carregue lentamente suas imagens. Mais importante, forneça imagens responsivas. Da mesma forma, você pode usar o atributo de conjunto de origem da tag de imagem ou a tag de imagem para fornecer imagens responsivas. Percebi que isso realmente leva a muitas melhorias, porque os principais indicadores vitais da Web são as primeiras medições móveis. Então é muito importante que você veicule imagens responsivas. É algo que nós meio que esquecemos às vezes.

Então eu acho que imagens. E também algumas coisas muito simples, como minimizar seu JavaScript em seu CSS durante as etapas de construção. Acho que isso ajuda muito também. É bem simples de fazer.

MATT CHASE: Sim. Sobre esse assunto, na verdade, desde que você mencionou, o WordPress distribui uma espécie de sistema de compilação de webpack empacotado. Eles apenas chamam isso de WordPress Scripts. E nossa agência lutamos por muito tempo tentando manter nosso próprio sistema de webpack. E então, a cada oito meses, mais ou menos, alguma dependência de nó mudaria e quebraria toda a nossa cadeia de ferramentas. Mas o WordPress meio que mantém isso para nós. E tem sido um grande benefício.

E o webpack lá, começamos a usar importações dinâmicas para construir nosso pacote JavaScript principal. Portanto, estamos meio que importando nossas dependências de nó no tempo de execução, em vez de agrupar tudo em um pacote JavaScript principal, o que nos permitiu um controle realmente ajustado sobre o mesmo tipo de carregamento de script adiado. Apenas em casos específicos. Como quando nosso bloco está na página.

MARK DAVOLI: Sim. Também acho muito importante garantir que você seja muito seletivo em relação aos plug-ins que usa em seu site. Você pode obter muitos bloatwares inesperados ao instalar plug-ins de terceiros. Portanto, tente limitá-los a plug-ins muito bem conceituados e bem construídos. E preste atenção no que esses plugins carregam. Isso realmente pode ajudar a controlar o desempenho do site. E, infelizmente, o WordPress ainda depende muito do jQuery para uso de back-end e outros enfeites. Mas não é realmente necessário para frontend. Portanto, se possível, descartar o suporte a jQuery do front-end do site e aderir ao JavaScript nativo pode realmente ajudar no desempenho.

ALEX ZUNIGA: Incrível. Acho que já estamos mergulhando nessa área. E você mencionou alguns. Mas vamos tocar um pouco mais nisso com o ferramental. Quais são algumas das ferramentas preferidas que você gosta de usar para a otimização do Core Web Vital? E para que tipo de casos de uso eles são melhores? Ou há alguns cenários em que eles não são adequados?

MATT CHASE: Quero dizer, isso surgiu antes. Mas, na verdade, a ferramenta Lighthouse no navegador é a minha escolha, porque são resultados imediatos. Certo. O Core Web Vitals é ótimo, mas seu poder está no fato de ser um agregado que se junta ao longo do tempo. Então você não pode realmente mudar alguma coisa e ver o número mudar. Em relação ao Lighthouse, no navegador, você faz uma atualização. Você vê seu ambiente de desenvolvimento local e executa um teste do Lighthouse. E posso ver imediatamente, oh, meu desempenho saltou 15 pontos. Legal. Essa era a coisa certa a fazer. Empurre isso para a produção.

ALEX ZUNIGA: Incrível. Quaisquer outras ferramentas que você gosta de usar?

MIKE CRANTEA: Gostaria de destacar o recurso de substituições locais no Chrome. Isso, em combinação com a guia Desempenho, oferece a você uma capacidade cirúrgica de alterar até mesmo a ordem de carregamento dos itens em seu site. E quanto ou pouco isso impacta. Dá a você a supervisão necessária para saber se vale a pena se esforçar para fazer uma determinada mudança ou se você simplesmente deixa para lá e se concentra em outras coisas que realmente causam impacto.

MARK DAVOLI: E uma coisa que eu acho que também é crítica é o monitoramento da arquitetura do servidor. Certo. Assim, você pode ter os maiores Núcleos Vitais da Web do mundo, mas se o seu servidor estiver sob uma carga extraordinariamente pesada e você não estiver ciente, poderá descobrir repentinamente que sua primeira pintura de conteúdo cai drasticamente, o que afeta praticamente todo o resto. Portanto, fique de olho em ferramentas como New Relic ou qualquer outra para apenas monitorar o desempenho. É fundamental ficar de olho apenas para garantir que você tenha a infraestrutura adequada para renderizar seu site o mais rápido possível.

MIKE CRANTEA: E é aí que ter o cache ativado e pronto ajuda.

MARK DAVOLI: E CDN.

MIKE CRANTEA: Sim. Evite alguns desastres em potencial.

ALEX ZUNIGA: Excelente. Bem, eu aprecio essa clareza lá. Então uma das questões. Existem muitos plugins de otimização para otimizar o Core Web Vitals. Quais são as limitações dos plugins do WordPress para ajudar nisso? Ou eles estão realmente otimizando o site? Ou eles estão apenas possivelmente enganando as medições do Google? E eu acho que talvez seja uma questão de, é melhor - nós meio que mencionamos, é melhor usar plugins ou fazer o trabalho em vez de confiar em um plugin lá?

SANJUCTA GHOSE: Acho que os plugins são ótimos. Como por exemplo, o WP Rocket por exemplo é ótimo. Usamos muito o EWWW Image Optimizer. E eu acho isso ótimo também. Mas como eu acho que já foi dito. WP Rocket, você deve usá-lo com cuidado, porque se você ativar o recurso de defer JavaScript, já vi casos em que ele apresenta bugs estranhos. Um erro. Portanto, às vezes, prefiro lançar minha própria solução em vez de usar um plug-in. Desde que você tenha experiência em desenvolvimento.

Portanto, a maioria das otimizações que fizemos para os sites do Delicious Brain foram feitas por conta própria, em vez de usar um plug-in. Mas dito isso, acho que os plugins são um ótimo ponto de partida. Portanto, quando você está apenas começando, pode querer, por exemplo, implementar o WP Rocket em seu site de teste e brincar e ver se ele quebra as coisas ou não. Ou se traz melhorias reais. Portanto, acho que os plugins devem ser usados ​​com cuidado. E você tem que saber o que está acontecendo em segundo plano, o que os plugins estão fazendo. E como isso pode afetar seu site.

MATT CHASE: Sim. Felizmente, o WP Rocket, acho que em versões mais recentes, pelo menos foi bom em rotular claramente os interruptores perigosos que eles têm. Porque eu também fui prejudicado por isso várias vezes, onde os scripts atrasados ​​- e mesmo aqueles que você não esperaria, como a otimização de CSS, de alguma forma quebraram modelos em que não obtiveram o que dizia que um nome de classe os tornaria visíveis . Então foi um dia emocionante.

Mas sim. O WP Rocket é definitivamente a minha escolha, além de obviamente um bom código de entrada, um bom código de saída. Certo. Fazer o trabalho é sempre a melhor maneira de abordá-lo. Plugins podem automatizar coisas. Mas não há substituto para realmente ter seu código enxuto e mesquinho.

MIKE CRANTEA: Há mais um plug-in marcado como um tipo de plug-in de laboratório. Isso é Performance Lab. É feito pela equipe principal de desempenho do WordPress. E mesmo que pareça algo assustador, forneceu em todos os meus testes até agora total estabilidade. E isso foi muito impressionante pelo que deveria ser e pela qualidade do trabalho que acabou naquele plug-in do Performance Lab. Então vale a pena experimentar. Algumas caixas de seleção. E tudo o que está lá dentro está seguro. Bem, não tenho tanta certeza sobre a troca de banco de dados. Isso é algo mais controverso quando leio sobre isso. Sim. Só não toque nesse botão. Como se eles adicionassem suporte a SQLite ou algo parecido dentro do plug-in, o que definitivamente está funcionando para alguns sites menores.

ALEX ZUNIGA: Interessante.

MARK DAVOLI: Sim. E para mim, o WP Rocket é fantástico. Limitamos seu uso na maioria de nossos sites porque a maior parte do que fazemos é construído nativamente. Mas há muitos outros recursos no Core WordPress que, se usados ​​corretamente, podem realmente resultar em um site bem otimizado. Como usar o Block Editor em vez de terceiros como Elementor ou etc, pode adicionar muito inchaço a um site. Portanto, se você criar como o novo sistema de bloco de tipo Gutenberg nativo e realmente carregar os arquivos conforme necessário, em vez de carregar tudo de uma vez em cada página, por exemplo. Há recursos de carregamento preguiçoso integrados no WordPress agora. Portanto, monitorar como é usado e usá-lo adequadamente, etc. E, em seguida, adicionar uma ferramenta como o WP Rocket para aprimorar o que já existe. Mas não contando apenas com isso.

Pode ser benéfico para você chegar lá, especialmente se você tiver um site que não funciona bem. Mas, como mencionado, como a geração crítica de CSS, essas coisas podem ter muitos problemas porque fazem muitas suposições com base no que o bot vê em sua página. Mas não pode prever coisas que não renderizarão visualizações iniciais. Portanto, se você tiver modelos, como mencionado, esses pop-up, não saberá que é uma possibilidade. Ele não gerará o CSS para ele e o alinhará corretamente. Então, como fazer coisas como pré-carregar suas principais fontes ou renderizá-las acima da dobra. Novamente, essa é a chave. Realmente o mais importante.

SANJUCTA GHOSE: No tópico de CSS crítico, eu só queria entrar e mencionar que Addy Osmani tem uma ferramenta incrível chamada Critical. Você pode adicionar isso ao seu processo de construção para gerar seu CSS crítico. É incrivel. E é muito confiável. Então, já que você mencionou CSS crítico, pensei em adicioná-lo. Desculpe por cortar você.

MIKE CRANTEA: Tudo bem. No mesmo tópico do CSS crítico, houve algum esforço da equipe Jetpack para fazer algo com o plug-in Jetpack Boost. Isso é uma maneira muito, muito interessante de gerar o CSS crítico renderizando as páginas em iframes ou algo assim. Isso fornece quando funciona, é uma ótima solução. Quando isso não acontece, ele diz, ei, não funciona aqui. Apenas siga em frente. Você precisa de algo mais. Nem sempre é fácil chegar ao CSS crítico. Por outro lado, 4 ou 5 anos atrás, o CSS crítico era super grande. Ele ajudou muito.

Nos últimos dois ou três anos com os avanços do HTTP/3, ter um CSS crítico que é renderizado bloqueando tem um impacto muito pequeno para ter 100 kilobytes ou algo do CSS inline. Está fazendo um site funcionar tão rápido quanto um site que costumava ter CSS crítico quatro ou cinco anos atrás. Portanto, não tenha medo de ter um CSS de tamanho decente dentro do seu site. Você não precisa se livrar dele. E eu vi sites que eram super otimizados.

Temos em CSS crítico como 100 kilobytes de CSS inline. E bloqueio de renderização, jQuery e outros dois scripts que não foram usados. É como, sim. Você está derrotando o propósito com isso. Pode nos ajudar a durar 5% do tipo de abordagem. Mas se você começar com isso, olhe para o primeiro.

ALEX ZUNIGA: Incrível. Incrível. Acho que todas essas ferramentas. É ótimo ouvir esses gritos. E ótimo ouvir essas sugestões e recomendações. E muito desse tipo gira em torno de nossa próxima pergunta. Quais são os aspectos exclusivos de trabalhar no WordPress especificamente com o Core Web Vitals? Você está tendo que fazer isso por meio de plug-ins em vez de fazê-lo com qualquer outra pilha de tecnologia? É mais fácil com o WordPress? Existem mais ferramentas disponíveis? Como acabamos de mencionar, todos vocês dispararam muitas ferramentas. É mais fácil com o WordPress? É mais difícil com o WordPress? O que vocês acham?

MATT CHASE: Acho que é muito fácil com o WordPress. Então, conversamos um pouco sobre– ou mencionei o pacote de nó de scripts do WordPress que eles distribuem, que é apenas um ótimo tipo de sistema de compilação de webpack em uma caixa. Eles também têm o bloco WordPress Create, que é apenas uma maneira realmente rápida e fácil de inicializar um bloco personalizado para o seu site baseado em WordPress. Mas é construído de tal forma que muito do código cola, por assim dizer, é escrito para você. Então já é inteligente sobre– Mark, você mencionou apenas esses scripts quando deveria. Então você sabe se o seu bloco está fazendo isso desde o início. Você nem precisa pensar nisso. Portanto, o WordPress torna esse tipo de coisa muito fácil.

MARK DAVOLI: Sim, com certeza. E é de código aberto. Certo? Então você pode mudar praticamente qualquer coisa. É muito mais difícil quando você está trabalhando com um sistema fechado para otimizar para Core Web Vitals versus WordPress por causa disso. E quando o Core Web Vitals foi anunciado pela primeira vez, ainda não estava lá. Foi muito mais desafiador. Eles realmente percorreram um longo caminho adicionando muitos desses recursos, especialmente com o editor de blocos e a construção baseada em blocos, etc., para realmente otimizar a capacidade de carregar ativos seletivamente, arquivos CSS, arquivos de fonte etc. Então sim. Tem sido ótimo.

ALEX ZUNIGA: Provavelmente é a questão do sistema fechado versus código aberto. Vá em frente, Sanjucta.

SANJUCTA GHOSE: Sim. Sim. E acho que porque há muitos provedores de hospedagem dedicados ao WordPress. E como você disse. O WordPress é de código aberto. Portanto, há muitas otimizações em relação à hospedagem de sites WordPress. E acho que já existe muito suporte disponível se você estiver construindo em cima do WordPress, o que significa que você não precisa reinventar a roda. Então, acho que é definitivamente mais fácil se você estiver construindo sobre o WordPress para otimizar seus Core Web Vitals.

ALEX ZUNIGA: Lindo. Falamos sobre como medimos essas ferramentas, o que usamos para realmente aprimorar nossas principais métricas da Web, algumas das ferramentas. Agora, quando estamos falando sobre as expectativas do cliente, em que estágio de um novo projeto você começa a considerar o Core Web Vitals como parte de sua construção ou estratégia? É isso mesmo quando você começa como seu modelo clichê básico? Ou é algo que você otimiza um pouco mais adiante na história? O que todos vocês fazem?

MATT CHASE: Sim. Acho que para mim é mais apenas uma maneira de construir as coisas para começar, mais do que uma coisa que você faz em um site não otimizado. É desde o começo. E está lá em cada linha de código que você escreve idealmente. Eu tento não – eu não quero construir um grande site otimizado, e então voltar mais tarde e consertá-lo. Quero tentar escrever o mais limpo possível desde o início. E então, geralmente, acho que fazer dessa maneira, espremer aquele último pouco de suco de otimização no final é um pouco mais fácil.

MARK DAVOLI: Sim. Ele está absolutamente correto. Começamos a construí-lo desde o início. Quero dizer, existem componentes que não acontecem mais perto do fim. Não vamos executar imagens por meio de uma otimização de imagem até mais perto do lançamento. Mas você realmente não precisa nem mesmo na construção em si, mas mesmo no processo de design, às vezes, é importante pensar em como o site está sendo projetado se você estiver levando em consideração o Core Web Vitals. Porque, arquitetonicamente, é mais desafiador implementar certos designs para serem rápidos do que outros. Portanto, entender isso e educar os designers sobre o que poderia tornar uma implementação mais difícil ou não é muito útil.

MIKE CRANTEA: E ditando os limites. Ei, você só pode ter até x telefones. Você não deve trazer 25 para a mesa com todas as suas variações. Isso ajuda desde a fase de design. Além disso, sem ter alguns pontos de contato que acontecem durante o projeto, às vezes é fácil resolver algumas coisas. Como um sprint, sete solicitações para adicionar um plug-in de questionário à mistura. Se isso não for verificado, você o encontrará um pouco no final. Portanto, minhas recomendações são processar isso a cada dois sprints. Verificamos nossas medições automatizadas da encenação de como as coisas evoluem. O que aconteceu com as últimas coisas que foram empurradas para ir? As coisas diminuíram? Precisamos fazer alguma medida corretiva antes do tempo, em vez de ser reativo no final de um projeto.

SANJUCTA GHOSE: Sim. Concordo. É muito importante que você comece desde a fase de design porque gosta de coisas simples como se deve haver um pop-up, um banner de anúncio ou algo assim. Às vezes, faz uma grande diferença para talvez sua pontuação cumulativa de layout. Então é bom saber de antemão o que vai acontecer. Se você vai ter um pop-up ou um banner chegando. E você não quer surpresas no final do seu projeto. Portanto, acho muito importante envolver o cliente ou as partes interessadas desde a fase de design e dizer a eles que isso pode ter um impacto em seus principais sinais vitais da Web, para que possam tomar uma decisão informada.

MARK DAVOLI: Isso também é super útil após o lançamento, porque assim que seu site estiver pronto, às vezes pode ser como, vamos lançar um widget de bate-papo ou algo assim mais tarde. Então, de repente, há uma torção. E então você tem que pensar em como podemos integrar e otimizar isso. Portanto, o recurso de scripts de atraso pode empurrar a maioria dos pixels de publicidade, que são notoriamente ruins para matar sua pontuação de Core Web Vitals. Mas às vezes você não pode atrasar algo porque é importante para o que o cliente realmente deseja. Portanto, equilibre-o da melhor maneira possível e certifique-se de comunicar os impactos potenciais. E apenas o resultado final é obtê-lo o mais rápido possível. Às vezes você tem que fazer sacrifícios pela funcionalidade. Às vezes você não. Mas faça isso o mais rápido possível para aumentar essas conversões.

ALEX ZUNIGA: Excelente. Excelente. Então, eu estou ouvindo isso como ingredientes melhores fazem sites melhores desde o início. Não que vamos apenas colocar alguns Core Web Vitals bem no final. É algo que realmente é um modo de vida, se você quiser pensar dessa maneira primeiro. Bem, incrível. Então, apenas a nossa última pergunta. Você já teve algum problema em transmitir o valor do tempo que gasta trabalhando no Core Web Vitals para seus clientes? Isso é algo que eles sempre empurram de volta? Eles nunca entendem por que você está fazendo esse trabalho?

MATT CHASE: Na verdade, acho que nunca recebi nenhum tipo de reação. Se alguma coisa, é meio que o oposto. Normalmente, queremos o desempenho. Queremos o Core Web Vitals. Vamos fazer acontecer. Devo dizer que nem sempre refletimos sobre– falamos sobre rastreamento de pixels e como eles são notórios por reduzir essa pontuação. Mas ninguém se importa. Somos como pixels, pixels, pixels, pixels. Portanto, as pessoas precisam pensar em realmente avaliar esse custo-benefício ao adicionar rastreamento, porque não é tão simples quanto apenas colocá-lo em prática e obter resultados. Porque há um custo.

ALEX ZUNIGA: Incrível.

MIKE CRANTEA: Acho que falta paciência com o desempenho. Então, se você está pensando, oh, vamos fazer algum trabalho de desempenho que durará alguns sprints, após o primeiro. Quando vejo? Quando vejo? Planejar lançá-lo iterativamente, como aumentar um recurso, um recurso, um recurso aumenta a confiança do impacto que esse trabalho causa. E quanto mais você vê isso se traduzir em conversões e mudanças, mais rapidamente o valor é percebido sem ter que gastar muito tempo fazendo o trabalho de educação.

MARK DAVOLI: Sim. E acho que uma coisa que pode ser complicada para os clientes entenderem é a diferença entre métricas reais do usuário e dados de laboratório. Porque muitos deles podem executar seus próprios testes e outros enfeites. E não entendo totalmente. Portanto, ajudá-los a entender que a parte do resumo de origem da página, seja os insights, é realmente aquele que o Google usa para efetuar a classificação de SEO e coisas assim. Porque muitos deles vêm buscando essa pontuação e otimizando isso. E ajudá-los a entender que leva 28 dias para medir qualquer mudança feita na produção antes que você tenha toda a gama de como sua mudança afetou as coisas.

ALEX ZUNIGA: Essa é uma ótima chamada. Grande chamada.

MIKE CRANTEA: E devo destacar uma das métricas que é a mais confusa de todas. As métricas de interatividade. Esses têm sido notoriamente voláteis. E para algum tipo de pessoa que tem mais medo de qualquer variação na pontuação, é como se esse novo recurso que construímos tornasse o site mais lento significativamente? E então, faça o teste novamente e é como subir 10 pontos e depois descer 10 pontos. Explicar essa variação é muito demorado. Por que não é apenas um número que é consistente? Bem, isso é algo tão difícil quanto nomear coisas e armazenar em cache.

ALEX ZUNIGA: Bem, incrível. Parece que realmente apreciamos a contribuição de todos vocês, todos os seus comentários sobre o Core Web Vitals. Como usá-los, o que usar para medi-los, como definir as expectativas do cliente para tudo isso. Tem sido realmente uma lição de aprendizado. Esperamos que nossos membros do painel tenham gostado do seu tempo aqui. Nós definitivamente gostamos de ouvir todos os seus comentários. E esperamos que os participantes aqui também tenham recebido um ótimo feedback.

Então, todos vocês, muito obrigado pelo seu tempo. Bem, esse foi o nosso painel. Nós realmente queremos dizer muito obrigado a todos os nossos palestrantes. Queremos agradecer a sua presença neste painel. E esperamos que você se divirta assistindo ao restante de nossas sessões a DE{CODE}.