Hora da segunda parte do meu relato e das mudanças aqui no Select Game envolvendo o Core Web Vitals, a atualização do Google que continua gerando muitas discussões na comunidade de SEO, e que, quem sabe, começar pra valer um movimento para que os sistemas de CMS carreguem as páginas de maneira mais eficiente. Pois de certa forma é isso: otimização de código, algo que o WordPress nunca teve tanta preocupação e que coube aos plugins de cache e ao AMP pra resolver essa questão.
Pois o AMP faz milagre, mas ainda não é a bala de prata que muitos querem ter. As páginas podem ter pontuações elevadas, mas depende demais do layout até mesmo do tema que a pessoa está usando no AMP. Fatores externos também influenciam, que vou comentar no decorrer desse artigo.
As discussões envolvendo o critério de ranqueamento do Google vão desde artigos criticando, de certa forma, a mudança, até mesmo o John Mu (um dos chefes da busca do Google) comentando mais sobre isso no Twitter. Segundo ele, quando um site carrega de forma lenta, ou um site está lotado de propagandas – aqui eu também me incluo por conta do Adsense, mas nunca quis exagerar, e por isso nunca consegui tanta grana com isso – os usuários culpam o Google por “ter mandado para um site com problemas”.
De certa forma concordo com o artigo de que o abacaxi da otimização caiu logo no colo dos editores, donos do portal, profissionais de SEO e Webmasters – e não foi por falta de aviso, já que desde o ano passado que isso estava sendo planejado. Quando questionaram num fórum de WordPress se eles deveriam pensar nisso (10 meses atrás), mandaram ir no fórum do Google. Aí complica.
E de certa forma o Google quer tentar fazer com que a tecnologia ande, que os sites se adaptem. Mas ainda não dá pra saber qual será o “peso” da otimização. Eu comecei a correr atrás, investi uma grana nisso (ao comprar um tema novo), investi muito tempo livre nisso, mas mesmo com um layout novo não dava garantias de que todas as páginas terão score alto.
E é aqui que começaram os meus problemas, soluções e otimizações. Mas como comentei no artigo anterior: o que terá no longo desse texto é uma opinião pessoal, meu relato da busca pra ter um site melhor, mas pode ser que no futuro apareçam soluções melhores.
Só que no momento eu só estou tendo uma despesa elevada com o site, já que o Adsense atual não consegue pagar um terço do custo que eu to tendo de hospedagem: R$ 254 reais. E não enxergo no momento que o blog consiga se pagar, mas eu já to tentando me mexer nesse sentido.
Mas nos últimos dias fiz uma mudança até então radical com o site: eu converti tudo pra AMP e comecei a mudar as coisas usando o sistema de base.
AMP nas páginas canônicas – Uma mudança radical de paradigma e do layout
O AMP é uma tecnologia que muitos já usavam pras páginas mobile. Boa parte dos sites de WordPress instalavam isso pra receber as visitas do celular, mas quando as pesquisas de celular começaram a ditar o rumo do tráfego, boa parte dos sites mantinham os 2 endereços, mas quem acessava via desktop ainda tinha a questão dos layouts bem elaborados e propagandas exageradas.
Eu usava este plugin de AMP, mas nos últimos meses me questionava sobre a questão da minha estrutura, dos problemas de performance pela quantidade exagerada de plugins, ou se eu deveria remover boa parte deles e ter menos recursos visuais. Com o Core Web Vitals em jogo, decidi usar o plugin oficial de AMP mantido pela AMP-WP.org.
Na minha busca por ter um score melhor aqui, eu cheguei a comprar este layout de WordPress, além de testar a versão trial do Litespeed Cache. Eu estava disposto a pagar R$ 400 reais por mês de custos, mas ao ser suspenso do Discover nos Web Stories (e sem plano de contingência) eu vi que não dava pra depender dos Web Stories pra ter tráfego – além do desânimo em criar novos posts nesse formato.
As páginas de Web Stories até que são bem indexadas e rápidas, mas sem isso, o patamar do Adsense retornou pra “quase nada”. Com alguma sorte ultrapassa 2 dólares num dia, mas em sua maioria fica entre 1 e 2, com um site com 2500 a 3000 visitas diárias. Se eu gastasse menos de hospedagem, tudo bem, mas no momento atual eu deveria fechar o site. Mas como ainda gosto de ter ele, ainda quero ver se consigo melhorar e ter mais visitas.
Mas voltemos ao AMP. No final de semana, ao criar um blog extra e fazer testes com o AMP, percebi que eu conseguia ter um score quase máximo nas páginas oficiais ao setar o plugin como “Padrão”. Ou seja: as páginas canônicas seriam renderizadas no formato AMP, diferente do formato tradicional onde tinha uma url oficial (site.com.br/analise) e uma página pareada (site.com.br/analise/amp/), com a segunda referenciando a primeira como sendo canônica. O leitor vindo do Google entrava direto na versão AMP da página.
Decidi também testar algumas páginas de portais concorrentes pra comprovar a minha teoria, e vi que um dos portais tinha feito essa mudança, de ter apenas 1 única URL. E com isso tinha pontuações muito elevadas no Pagespeed Insights e em outros locais, como o Lighthouse. Decidi fazer o teste e iniciei a conversão.
Mas tem um problema: mudar as páginas pra AMP acaba limitando o usuário com relação a algumas otimizações e plugins que ele pode estar utilizando e pode ter pago uma grana nisso. Por exemplo o WP-Rocket, que tem uma série de otimizações, mas que acaba quebrando a página. Pois o AMP não permite que tenha javascript customizado. As opções problemáticas (no momento) são similares a essas: “Load CSS Asynchronously” e “Load JS Deferred”. Essas 2 são opções do Litespeed que prometem melhorar o score e que tem em plugins similares, mas ativar elas gerou um problema enorme. Sorte que dessa vez eu consegui detectar rápido.
Ter detectado rápido e ter anotado os passos pra desfazer me ajudaram a consertar o problema.
Continuei a conversão e comecei a ter uma melhora substancial de pontuação. Mas ainda insuficiente pra chegar no 90.
É uma solução interessante pro Core Web Vitals? Sim, mas os desenvolvedores podem tentar depois alternativas e testes, principalmente se o dono do portal tenha pagado o Wp-Rocket. Mas algumas operações são arriscadas, já que não dá pra saber se um layout do WordPress (pago ou gratuito) terá uma boa pontuação. Muitos desenvolvedores e empresas que vendem temas de WordPress vão tentar “vender” a ideia de que o tema deles tem score de 100% no Core Web Vitals. Mas não dá pra testar antes, e a compra de um layout pode trazer uma carga altíssima de frustração, já que não dá pra ter reembolso.
O que eu recomendo é inicialmente testar os plugins e temas gratuitos. Sei que será difícil encontrar um que agrade visualmente, mas pra quem tem poucos recursos, inicialmente é uma alternativa a se considerar.
Já sobre o AMP, os desenvolvedores estiveram empenhadíssimos em entregar uma experiência de performance, e que ofereça pouco trabalho pro dono do portal. Até o John Mu reconheceu isso no Twitter:
“Não estou 1000% “vendido” em tudo relacionado ao AMP, mas o trabalho que vi de pessoas como @iAlbMedina e a equipe no plugin AMP no WP é super-impressionante. Tornar um site WordPress rápido pode ser muito difícil, mesmo se você codificar e ajustar. Ter um plugin que basicamente leva você até lá com o mínimo de trabalho é impressionante”.
John Mu, via Twitter
Mas ele tem uma ressalva sobre isso e sobre o ranking do Google:
“Isso parece certo. Mudar para AMP na esperança de obter uma classificação melhor é a motivação errada. Se você tiver um site lento, o AMP pode torná-lo rápido e isso, por sua vez, pode ser útil para a classificação, mas a resposta é “torná-lo rápido”, não necessariamente “mudar para AMP” (é só que o AMP também é rápido)”.
John Mu , via Twitter
Não apenas na classificação e sim na própria experiência do usuário. Ter menos tempo pra pessoa carregar a página pode ser útil e a pessoa retornar depois, ou até continuar no site e ver outros posts.
Mas tem uma questão que a maioria não via antes até começar a testar as páginas. Os embeds de redes sociais e as diferenças de pontuação entre os medidores de performance.
Embeds, uma das pedras no sapato do Lighthouse (e similares)
Aqui não tem uma solução de imediato, pois não depende do Google, e sim das outras empresas. Dependendo de qual página você testa, poderá aparecer nos reports que o Twitter “não codificava” as imagens de última geração, ou que era ideal “armazenar arquivos estáticos em cache”.
Ou mesmo os avisos de “warning” de que “a página fez um pré-connect” com uma imagem:
Um <link rel=preconnect> foi encontrado para “https://s.ytimg.com”, mas não foi usado pelo navegador. Use preconnect apenas para origens importantes que certamente serão solicitadas pela página.
Essa questão é levantada nos embeds de Instagram e no Youtube é mais complicado por conta das trumbnails ainda estarem usando JPG tradicional. Não sei se o Google pretende reencodar toda a base de thumbs do Youtube pra WEBP em um primeiro momento, mas certamente isso geraria uma economia de banda enorme.
Claro que esse aviso de pré-connect é ir no cerne do cerne da otimização, mas na prática tem outros elementos pra se preocupar.
Também teve uma pessoa que comentou de estar com o score baixo pro John Mu, que comentou que, se um score está baixo, não significa automaticamente que o site esteja com problemas de indexação. E que o Lighthouse pode apontar onde está o erro.
Nos reports mais recentes do Pagespeed Insights e do Lighthouse (no plugin do Chrome) não acusa mais a questão dos embeds e do javascript quando a página testada é AMP. Mas se a página estiver ainda usando HTML tradicional, irá exibir que as imagens dos embeds estão sem compressão.
Até mesmo uma propaganda do Adsense (ou de outro serviço similar) pode não estar em conformidade com o Core Web Vitals! As imagens de uma propaganda podem estar em formato sem compressão, e aí não tem muito o que fazer: ou mantém o sistema de propaganda, ou remove e fica sem (parte do) faturamento. Ou continua do jeito que está e a página ficará com um score mais baixo.
Isso pode criar uma mudança de paradigma até na criação de conteúdo. Se algum site usa muito embeds de Twitter e quer manter score alto, provavelmente alguns podem optar por fazer um print do tweet, ou nem usar isso nas páginas, deixando a imagem com uma URL apontando pro tweet. Ou esperar e ver os avanços do desenvolvimento de ferramentas pra otimizar isso, mas como comentei antes: ainda não dá pra saber o “peso” do score no ranking final.
No próximo artigo vou comentar mais sobre o meu entendimento do LCP e as tentativas de melhorar o score nas páginas. A minha luta está longe de acabar.