O Que São o Core Web Vitals e Como Você Pode Melhorá-los?

As métri­c­as da exper­iên­cia da pági­na para dis­pos­i­tivos móveis e as métri­c­as do Core Web Vital foram ofi­cial­mente usadas para clas­si­ficar pági­nas web des­de maio de 2021. Os sinais da área de tra­bal­ho tam­bém foram usa­dos a par­tir de fevereiro de 2022.

A maneira mais fácil de ver­i­ficar as métri­c­as do seu web­site é com o relatório Core Web Vitals no Google Search Con­sole. Com o relatório, você poderá ver facil­mente se as suas pági­nas estão cat­e­go­rizadas como “URLs de má qual­i­dade”, “URLs que pre­cisam ser mel­ho­radas” ou “URLs boas”.

Os lim­ites para cada cat­e­go­ria são os seguintes:

E aqui fica como o relatório se parece:

Se você clicar em um dess­es relatórios, obterá um detal­he muito mel­hor dos prob­le­mas rela­ciona­dos com a cat­e­go­riza­ção e o número de URLs afetadas.

Clicar em um dos prob­le­mas em par­tic­u­lar fornece um detal­he maior sobre os gru­pos de pági­nas afe­tadas. Este agru­pa­men­to de pági­nas faz muito sen­ti­do, sendo que isso ocorre porque a maio­r­ia das alter­ações para mel­ho­rar os Core Web Vitals são feitas para um mod­e­lo de pági­na especí­fi­co, que por sua vez afe­ta muitas out­ras pági­nas. Você faz as alter­ações uma vez no mod­e­lo e isso será rap­i­da­mente cor­rigi­do nas pági­nas ref­er­entes a esse grupo.

Ago­ra que você sabe quais as pági­nas que são afe­tadas, aqui estão mais algu­mas infor­mações sobre o Core Web Vitals e como você pode faz­er com que as suas pági­nas passem no proces­so de verificação:

• Fac­tos rápi­dos sobre os Core Web Vitals
• Os Core Web Vitals são impor­tantes para SEO?
• Com­po­nentes do Core Web Vitals
• Fer­ra­men­tas para medir os Core Web Vitals

Fac­to 1: Os sinais móveis são usa­dos para clas­si­fi­cações de dis­pos­i­tivos móveis e os sinais de desk­top são usa­dos para clas­si­fi­cações de computadores.

Fac­to 2: Os dados vêm do Relatório de Exper­iên­cia do Usuário do Chrome (CrUX), que reg­ista dados de usuários do Chrome que optaram por par­tic­i­par na exper­iên­cia. As métri­c­as são avali­adas no per­centil número 75 de usuários. Por­tan­to, se 70% dos seus usuários estiverem na cat­e­go­ria “bom” e 5% estiverem na cat­e­go­ria “pre­cisa de mel­ho­rar”, a sua pági­na ain­da será avali­a­da com a cat­e­go­ria de como “pre­cisa de melhorar”.

Fac­to 3: As métri­c­as são avali­adas para cada pági­na, con­tu­do se não hou­verem dados sufi­cientes, o anal­ista de tendên­cias do Web­mas­ter do Google, John Mueller, declara que podem ser usa­dos sinais de seções em par­tic­u­lar de um web­site ou do web­site em ger­al. Através do nos­so estu­do de dados Core Web Vitals, anal­isamos mais de 42 mil­hões de pági­nas e desco­b­ri­mos que ape­nas 11,4% das pági­nas tin­ham métri­c­as asso­ci­adas a elas.

Fac­to 4: Com a adição dessas novas métri­c­as, as “Accel­er­at­ed Mobile Pages” (AMP) foram removi­das como um req­ui­si­to do recur­so de nome “Top Sto­ries” para dis­pos­i­tivos móveis. Como, por sua vez, essas novas histórias não terão dados sobre as métri­c­as de veloci­dade, é prováv­el que as métri­c­as de uma cat­e­go­ria maior de pági­nas (ou mes­mo todo o domínio) pos­sam ser usadas.

Fac­to 5: Os aplica­tivos de pági­na úni­ca não medem algu­mas métri­c­as, neste caso FID e LCP, através de tran­sições de pági­na. Exis­tem algu­mas alter­ações pro­postas, incluin­do a “App His­to­ry API” e pos­sivel­mente uma alter­ação na métri­ca usa­da para medir a inter­a­tivi­dade que seria chama­da de “Respos­ta”.

Fac­to 6: As métri­c­as podem mudar ao lon­go do tem­po e, con­se­quente­mente, os seus lim­ites tam­bém. O Google já alter­ou as métri­c­as uti­lizadas para medir a veloci­dade em todas as suas fer­ra­men­tas ao lon­go dos anos, bem como os seus lim­ites para o que é con­sid­er­a­do rápi­do ou não.

Os Core Web Vitals já foram alter­ados e estão em cur­so mais alter­ações pro­postas nas métri­c­as. Eu não ficaria sur­pre­so se o taman­ho da pági­na fos­se uma das métri­c­as adi­cionadas. Você pode ultra­pas­sar as métri­c­as atu­ais dan­do pri­or­i­dade aos con­teú­dos no ati­vo e, mes­mo assim, acabar por ter uma pági­na extrema­mente grande. Se assim for, será uma per­da de opor­tu­nidade muito grande, na min­ha opinião.

Exis­tem mais de 200 fatores de clas­si­fi­cação no Google, muitos dos quais não têm muito peso. Ao falar sobre os Core Web Vitals, os rep­re­sen­tantes do Google ref­er­em-se a eles como “minús­cu­los fatores de clas­si­fi­cação” ou até mes­mo de desem­pate para a clas­si­fi­cação final. Não espero mui­ta, se algu­ma, mel­ho­ria nos rank­ings ao mel­ho­rar os Core Web Vitals. Ain­da assim, eles são um fator, e este tweet de John mostra como um impul­so nos CWV pode funcionar.

https://twitter.com/JohnMu/status/1395798952570724352

Exis­tem fatores de clas­si­fi­cação que visam métri­c­as de veloci­dade já há muitos anos. Por­tan­to, eu não esper­a­va muito impacto visív­el quan­do a atu­al­iza­ção da exper­iên­cia da pági­na móv­el fos­se lança­da. Infe­liz­mente, tam­bém ocor­reram algu­mas atu­al­iza­ções prin­ci­pais do Google durante o perío­do de tem­po para a atu­al­iza­ção do Page Expe­ri­ence, o que tor­na a deter­mi­nação do impacto muito con­fusa para tirar uma conclusão.

Exis­tem alguns estu­dos que encon­traram algu­ma cor­re­lação pos­i­ti­va entre pas­sar no Core Web Vitals e mel­hores clas­si­fi­cações, mas eu pes­soal­mente olho para ess­es resul­ta­dos com ceti­cis­mo. É como diz­er que um site foca­do em SEO tende a ter uma clas­si­fi­cação mel­hor. Se um site já está tra­bal­han­do no Core Web Vitals, provavel­mente tam­bém fez muitas out­ras coisas cor­re­ta­mente. E as pes­soas tra­bal­haram neles, como você pode ver no grá­fi­co abaixo do nos­so estu­do de dados.

Vamos olhar para cada uma das métri­c­as Core Web Vitals em maior detalhe.

Aqui ficam três com­po­nentes atu­ais do Core Web Vitals e como medi-las:

• Largest Con­tent­ful Paint (LCP) – Car­ga visu­al (maior ren­der­iza­ção de conteúdo)
• Cumu­la­tive Lay­out Shift (CLS) – Esta­bil­i­dade visu­al (deslo­ca­men­to cumu­la­ti­vo de layout)
• First Input Delay (FID) – Inter­a­tivi­dade (primeiro atra­so de entrada)

Observe que há Web Vitals adi­cionais que servem como medi­das de proxy ou métri­c­as com­ple­mentares, mas não são usadas nos cál­cu­los de clas­si­fi­cação. As métri­c­as do Web Vitals para car­ga visu­al incluem Tem­po até ao Primeiro Byte (TTFB) e First Con­tent­ful Paint (FCP). As out­ras métri­c­as, Total Block­ing Time (TBT) e Time to Inter­ac­tive (TTI), aju­dam a anal­is­ar a interatividade.

Largest Contentful Paint

LCP é úni­ca grande ele­men­to vísiv­el car­rega­do no chama­do “view­port”.

Fonte: web.dev

O maior ele­men­to será, por nor­ma, uma imagem em destaque ou talvez a tag <h1>. Con­tu­do, tam­bém pode ser qual­quer um destes:

• ele­men­to <img>
• ele­men­to <image> den­tro de um ele­men­to <svg>
• Imagem den­tro de um ele­men­to <video>
• Imagem de fun­do car­rega­da jun­ta­mente com a função url()
• Blo­cos de texto

Os <svg> e <video> podem ser adi­ciona­dos futuramente.

Como ver o estado do LCP

No Page­Speed Insights, o ele­men­to LCP será especi­fi­ca­do na seção “Diag­nós­ti­co”. Além dis­so, observe que há uma guia para sele­cionar o LCP que mostrará ape­nas os prob­le­mas rela­ciona­dos com o mesmo.

No Chrome Dev­Tools, siga os seguintes passos:

1. Per­for­mance > ver­i­fique “Screen­shots”
2. Clique em “Start pro­fil­ing and reload page”
3. O LCP está no grá­fi­co que mostra o perío­do temporal
4. Clique no nó/interseção; esse será o ele­men­to para ver o LCP

Otimizando o LCP

Como vimos no Page­Speed Insights, há muitos prob­le­mas que pre­cisam de ser resolvi­dos, tor­nan­do o LCP a métri­ca mais difí­cil de mel­ho­rar, na min­ha opinião. Através do nos­so estu­do, notei que a maio­r­ia dos web­sites não pare­cia mel­ho­rar o seu LCP ao lon­go do tempo.

Aqui estão alguns con­ceitos a serem relem­bra­dos e algu­mas maneiras de mel­ho­rar o LCP de for­ma mais eficaz.

1. Mais pequeno é mais rápido

Se você pud­er se livrar de qual­quer arqui­vo ou reduzir os seus taman­hos, a sua pági­na será car­rega­da mais rap­i­da­mente. Isso sig­nifi­ca que você pode quer­er excluir todos os arquiv­os que não estão sendo usa­dos ou partes do códi­go que não estão sendo usadas.

A for­ma como você vai faz­er isso depen­derá muito da sua con­fig­u­ração, mas o proces­so é geral­mente chama­do de “trep­i­dação da árvore”. Isso é nor­mal­mente exe­cu­ta­do por meio de algum tipo de proces­so autom­a­ti­za­do. Ain­da assim, em alguns sis­temas, essa eta­pa pode não valer o esforço dispendido.

Há tam­bém a táti­ca da com­pactação, o que tor­na os taman­hos dos arquiv­os bem menores. Prati­ca­mente todo o tipo de arqui­vo usa­do para con­stru­ir o seu web­site pode ser com­pacta­do, incluin­do CSS, JavaScript, Ima­gens e HTML.

2. Mais perto é mais rápido

A infor­mação leva tem­po para via­jar. Quan­to mais longe você estiv­er de um servi­dor, mais tem­po levará para que os dados sejam trans­feri­dos. A menos que você aten­da a uma peque­na área geográ­fi­ca, ter uma rede de dis­tribuição de con­teú­do (CDN) é uma boa ideia.

As CDNs ofer­e­cem uma maneira de conec­tar e servir o seu web­site como se estivesse bas­tante mais próx­i­mo dos usuários geografi­ca­mente dis­tantes. É como ter cópias do seu servi­dor em difer­entes locais à vol­ta do mundo.

3. Use o mesmo servidor, se possível

Quan­do você se conec­ta a um servi­dor pela primeira vez, há um proces­so que ocorre, que nave­ga pela web, e esta­b­elece uma conexão segu­ra entre você e o servi­dor. Isso leva algum tem­po, e cada nova conexão que você pre­cisa de faz­er adi­ciona um atra­so extra, enquan­to pas­sa pelo mes­mo proces­so. Se você hospedar os seus recur­sos no mes­mo servi­dor, poderá elim­i­nar ess­es atra­sos extras.

Se você não pud­er usar o mes­mo servi­dor, con­vém usar a pré-conexão ou a bus­ca preparatória de DNS para ini­ciar as conexões mais cedo. Um nave­g­ador nor­mal­mente espera que o down­load do HTML ter­mine antes de ini­ciar uma conexão. Porém, com pré-conexão ou pré-bus­ca de DNS, ele começa mais cedo do que habit­u­al. Observe que a bus­ca preparatória de DNS tem mel­hor suporte do que a pré-conexão.

4. Limpe os dados que conseguir do seu Cache

Quan­do você armazena recur­sos em cache, ess­es recur­sos são baix­a­dos para a primeira visu­al­iza­ção de pági­na, mas não pre­cisam de ser baix­a­dos para visu­al­iza­ções de pági­na seguintes. Com os recur­sos já disponíveis, os car­rega­men­tos de pági­nas adi­cionais serão muito mais rápi­dos. Con­fi­ra como poucos arquiv­os são descar­rega­dos no car­rega­men­to da segun­da pági­na nos grá­fi­cos abaixo.

Primeiro car­rega­men­to da página:

Segun­do car­rega­men­to da página:

5. Prioritização de recursos

Para pas­sar na ver­i­fi­cação do LCP, você deve dar pri­or­i­dade à for­ma como os seus recur­sos são car­rega­dos no cam­in­ho de ren­der­iza­ção mais críti­co. O que quero diz­er com isso é que você deve reor­ga­ni­zar a ordem em que os recur­sos são baix­a­dos e proces­sa­dos. Você deve primeiro car­regar os recur­sos necessários para obter o con­teú­do que os usuários veem ime­di­ata­mente e, em segui­da, car­regar o restante.

Muitos web­sites podem chegar a tem­po para o LCP ape­nas adi­cio­nan­do algu­mas instruções de pré-car­rega­men­to para coisas como a imagem prin­ci­pal, bem como fol­has de esti­lo e fontes necessárias. Vamos ver como otimizar os vários tipos de recursos.

Imagens Cedo

Se você não pre­cisa da imagem, a mel­hor solução é sim­ples­mente se livrar dela. Se você pre­cis­ar da imagem, sugiro otimizar o taman­ho e a qual­i­dade para man­tê-la o menor possível.

Além dis­so, você pode quer­er pré-car­regar a imagem, o que vai ini­ciar o down­load dessa mes­ma imagem um pouco mais cedo. Isso sig­nifi­ca que ela será exibi­da um pouco mais cedo. Uma instrução de pré-car­rega­men­to para uma imagem respon­si­va tem esta aparência:

<link rel="preload" as="image" href=“cat.jpg"
imagesrcset=“cat_400px.jpg 400w,
cat_800px.jpg 800w, cat_1600px.jpg 1600w"
imagesizes="50vw">

Imagens Tarde

Você deve car­regar com “preguiça” todas as ima­gens que não pre­cisa ime­di­ata­mente. Isso car­rega ima­gens pos­te­ri­or­mente ao lon­go do proces­so ou quan­do um usuário está per­to de vê-las. Você pode usar loading=“lazy” assim:

<img src=“cat.jpg" alt=“cat" loading="lazy">

CSS Cedo

Já falam­os sobre remover CSS não uti­liza­do e reduzir o CSS que você tem atual­mente. A out­ra coisa impor­tante que você deve faz­er é “alin­har” o CSS em esta­do já críti­co. O resul­ta­do dis­so será pegar a parte do CSS necessária para car­regar o con­teú­do que os usuários veem ime­di­ata­mente e depois aplicá-lo dire­ta­mente no HTML. Quan­do o HTML é baix­a­do, todo o CSS necessário para car­regar e supor­tar o que os usuários veem já estará disponível.

CSS Tarde

Com qual­quer CSS extra que não seja críti­co, você vai quer­er aplicá-lo mais tarde no proces­so. Você pode ir em frente e começar a baixar o CSS com uma instrução de pré-car­rega­men­to, mas não aplicar o CSS até mais tarde com um even­to “onload”. Isso se parece com:

<link rel="preload" href="stylesheet.css" as="style" >

Fontes

Vou dar algu­mas opções aqui para o que eu acho que é:

Bom: pré-car­regue as suas fontes. Mel­hor ain­da se você usar o mes­mo servi­dor para se livrar da conexão.

Mel­hor: Exibição de fonte: opcional. Isso pode ser com­bi­na­do com uma instrução de pré-car­rega­men­to. Dessa for­ma dará à sua fonte uma peque­na janela de tem­po para poder car­regar. Se a fonte não chegar a tem­po, o car­rega­men­to ini­cial da pági­na sim­ples­mente mostrará uma fonte padrão. A sua fonte per­son­al­iza­da será armazena­da em cache e exibi­da em car­rega­men­tos de pági­na subsequentes.

Mel­hor: Bas­ta usar uma fonte do sis­tema por pré-definição. Não há nada para car­regar, por­tan­to, não haverão atrasos.

JavaScript Cedo

Já falam­os sobre remover JavaScript não uti­liza­do e reduzir o que você tem. Se estiv­er a uti­lizar uma estru­tu­ra JavaScript, con­vém pré-ren­derizar ou ren­derizar no lado do servi­dor (SSR) a página.

As out­ras opções são inserir o JavaScript necessário o mais ante­ci­pada­mente pos­sív­el. É semel­hante ao que dis­cu­ti­mos sobre CSS, onde você car­rega partes do códi­go den­tro do HTML ou pré-car­rega os arquiv­os JavaScript para obtê-los mais cedo. Isso deve ser feito ape­nas para con­teú­dos necessários, de for­ma a car­regarem esse mes­mo con­teú­do aci­ma da dobra ou se algu­ma fun­cional­i­dade depen­der desse JavaScript.

JavaScript Tarde

Qual­quer JavaScript que você não pre­cise ime­di­ata­mente deve ser car­rega­do mais tarde. Exis­tem duas maneiras prin­ci­pais de faz­er isso — atrib­u­tos adi­a­dos e assín­cronos. Ess­es atrib­u­tos podem ser adi­ciona­dos às suas tags de script.

Nor­mal­mente, um script sendo baix­a­do blo­queia o anal­isador durante o down­load e a exe­cução. Async per­mi­tirá que a análise e o down­load ocor­ram ao mes­mo tem­po, mas ain­da blo­queará a análise durante a exe­cução do script. O adi­a­men­to não blo­queará a análise durante o down­load e só será exe­cu­ta­do depois que o HTML ter­mi­nar de analisar.

Qual você deve usar? Para qual­quer coisa que queira mais cedo ou que ten­ha dependên­cias, vou optar pelo assín­crono (async). Por exem­p­lo, cos­tu­mo usar async em tags de análise para que mais usuários sejam reg­is­ta­dos com suces­so. Você vai quer­er adi­ar (defer) qual­quer coisa que não seja necessária para mais tarde ou que não ten­ha dependên­cias. Os atrib­u­tos são muito fáceis de adi­cionar. Con­fi­ra estes exemplos:

Nor­mal:

<script src="https://www.domain.com/file.js"></script>

Async:

<script src="https://www.domain.com/file.js" async></script>

Defer:

<script src="https://www.domain.com/file.js" defer></script>

Misc

Exis­tem algu­mas out­ras tec­nolo­gias que você pode quer­er anal­is­ar para apoiar no desem­pen­ho. Essas tec­nolo­gias incluem o Spec­u­la­tive Pre­ren­der­ing, Ear­ly Hints, Signed Exchanges, e HTTP/3.

Recursos

• Otimize o Largest Con­tent­ful Paint — web.dev
• Paul Irish (video) Inves­ti­gar o Largest Con­tent­ful Paint — vídeo de Paul Irish
• Como mel­ho­rar a Veloci­dade da Pági­na do Iní­cio ao Fim — Ahrefs

Cumulative Layout Shift

O CLS (deslo­ca­men­to cumu­la­ti­vo de lay­out) mede como os ele­men­tos se movem ou quão estáv­el é o lay­out da pági­na. Leva em con­sid­er­ação o taman­ho do con­teú­do e a dis­tân­cia que ele se move, sendo que, por out­ro lado, o Google já atu­al­i­zou como o CLS é medi­do. Ante­ri­or­mente, o CLS con­tin­uar­ia a ser medi­do mes­mo após o car­rega­men­to ini­cial da pági­na, mas ago­ra está restri­to a um perío­do de cin­co segun­dos, onde ocorre a maior mudança.

Fonte: web.dev

Pode ser bas­tante irri­tante se você ten­tar clicar em algo em uma pági­na que muda e acabar cli­can­do em algo que não pre­tende. Isto acon­tece comi­go o tem­po todo. Cli­co em uma coisa e, de repente, ver­i­fi­co que estou a clicar em um anún­cio e… nem estou no mes­mo web­site. Enquan­to usuário, acho isso frustrante.

Causas comuns de CLS incluem:

• Ima­gens sem dimen­sões definidas.
• Anún­cios, con­teú­do embed e iframes sem dimensões.
• Inje­tar con­teú­do no web­site usan­do JavaScript.
• Aplicar fontes ou esti­los tar­dia­mente na fase de carga.

Como ver o estado do CLS

No Page­Speed Insights, se você sele­cionar CLS, poderá ver todos os prob­le­mas rela­ciona­dos. O prin­ci­pal a se prestar atenção aqui é “Evite grandes mudanças de layout”.

Nós usamos Web­PageTest. Na Vista “Film­strip”, use as seguintes opções:

• Realçar Mudanças de Layout
• Taman­ho da Miniatu­ra: enorme
• Inter­va­lo da Miniatu­ra: 0.1 segundos

Observe como a nos­sa fonte muda de esti­lo entre 5,1 segun­dos e 5,2 segun­dos, mudan­do o lay­out con­forme a nos­sa fonte per­son­al­iza­da é aplicada.

A Smash­ing Mag­a­zine tam­bém tin­ha uma téc­ni­ca inter­es­sante em que delin­ea­va e sub­lin­ha­va tudo com uma lin­ha ver­mel­ha sól­i­da de 3px, enquan­to grava­va um vídeo do car­rega­men­to da pági­na para iden­ti­ficar onde as mudanças de lay­out estavam a ter lugar.

Otimizando o CLS

Na maio­r­ia dos casos, para otimizar o CLS, você tra­bal­hará em prob­le­mas rela­ciona­dos com ima­gens, fontes ou, pos­sivel­mente, con­teú­do inje­ta­do. Vejamos cada caso em maior detalhe.

Imagens

Para ima­gens, o que você pre­cisa de faz­er é reser­var o espaço das mes­mas para que não haja qual­quer deslo­ca­men­to e para que a imagem sim­ples­mente preen­cha esse espaço. Isso pode sig­nificar ter de definir a altura e a largu­ra das ima­gens, especi­f­i­can­do-as den­tro da tag <img> da seguinte forma:

<img src=“cat.jpg" width="640" height="360" alt=“cat with string" />

Para ima­gens respon­si­vas, você terá de usar src­set da seguinte forma:

<img

width="1000"

height="1000"

src="puppy-1000.jpg"

srcset="puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"

alt="Puppy with balloons" />

E reserve o espaço máx­i­mo necessário para qual­quer con­teú­do dinâmi­co, tal como con­teú­do usa­do em anúncios.

Fontes

Para fontes, o obje­ti­vo é obter a fonte na tela o mais rap­i­da­mente pos­sív­el e não trocá-la por qual­quer out­ra. Quan­do uma fonte é car­rega­da ou alter­a­da, você aca­ba com uma mudança per­cep­tív­el como um Flash de tex­to invisív­el (FOIT) ou Flash de tex­to sem esti­lo (FOUT).

Se você pud­er usar uma fonte do sis­tema, faça isso. Não há nada para car­regar, por­tan­to, não há atra­sos ou alter­ações que causem uma mudança.

Se você pre­cis­ar de usar uma fonte per­son­al­iza­da, o mel­hor méto­do atu­al para min­i­mizar o CLS é com­bi­nar  <link rel=”preload”> (que ten­tará pegar a sua fonte o mais rápi­do pos­sív­el) e exibição de fonte: opcional (que vai dar à sua fonte uma peque­na janela de tem­po para car­regar). Se a fonte não chegar a tem­po, o car­rega­men­to ini­cial da pági­na sim­ples­mente mostrará uma fonte padrão. A sua fonte per­son­al­iza­da será armazena­da em cache e exibi­da em car­rega­men­tos de pági­na consequentes.

Conteúdo injetado

Quan­do o con­teú­do é inseri­do de for­ma dinâmi­ca aci­ma do con­teú­do exis­tente, isso causa uma mudança de lay­out. Se você for faz­er isso, reserve espaço sufi­ciente para tal com algu­ma antecedência.

Recursos

• O que provo­ca Layout/Reflow — Paul Irish
• Otimizar CLS — web.dev
• Depu­ração de mudanças de lay­out — web.dev
• Enten­der CLS — vídeo de Annie Sullivan 
• Como evi­tar mudanças no Lau­out cau­sadas por Fontes Web — Simon Hearne
• Evoluir CLS através de fer­ra­men­tas da Web

First Input Delay

O FID (Primeiro atra­so de entra­da) é o tem­po que ocorre des­de quan­do um usuário inter­age com a sua pági­na até quan­do a pági­na efe­ti­va­mente responde. Você tam­bém pode pen­sar nis­so como a capaci­dade de resposta.

Exem­p­los de interações:

• Cli­can­do em um link ou botão
• Inserindo tex­to em um cam­po em branco
• Sele­cio­nan­do um menu suspenso
• Cli­can­do em uma caixa de seleção

Alguns even­tos como rolagem ou zoom não são contabilizados.

Pode ser frus­trante ten­tar clicar em algo e não acon­te­cer nada na pági­na.

Fonte: web.dev

Nem todos os usuários irão inter­a­gir com uma deter­mi­na­da pági­na, por isso a pági­na pode não ter um val­or FID. É tam­bém por isso que as fer­ra­men­tas de teste de lab­o­ratório não terão val­or porque não estão inter­agin­do com a pági­na. O que você pode quer­er olhar para os testes de lab­o­ratório é o Tem­po Total de Blo­queio (TBT). No Page­Speed Insights, você pode usar a guia TBT para ver prob­le­mas relacionados.

O que causa esse atraso?

A respos­ta é o JavaScript com­petindo pelo thread prin­ci­pal. Há ape­nas um thread prin­ci­pal e o JavaScript com­pete para exe­cu­tar tare­fas nele. Pense nis­so como JavaScript ten­do que se revezar para ser executado.

Fonte: web.dev

Enquan­to uma tare­fa está em exe­cução, uma pági­na não pode respon­der à entra­da do usuário. Este é o atra­so que se sente. Quan­to mais lon­ga a tare­fa, maior o atra­so expe­ri­en­ci­a­do pelo usuário. Os inter­va­l­os entre as tare­fas são as opor­tu­nidades que a pági­na tem para alternar para a tare­fa de entra­da do usuário e respon­der ao que eles que­ri­am fazer.

Otimizando o FID

Se você estiv­er inseri­do em uma estru­tu­ra JavaScript, haverá muito JavaScript necessário para a pági­na car­regar. Esse JavaScript pode demor­ar um pouco para ser proces­sa­do no nave­g­ador e isso pode causar atra­sos. Se você usa pré-ren­der­iza­ção ou (SSR), você trans­fere essa car­ga do nave­g­ador para o servidor.

Out­ra opção é dividir o JavaScript para que ele seja exe­cu­ta­do em tem­po menor. Você acol­he aque­las tare­fas lon­gas que atrasam a respos­ta à entra­da do usuário e as divide em tare­fas menores que blo­queiam por menos tem­po. Isso é feito com a divisão de códi­go, que divide as tare­fas em partes menores.

Há tam­bém a opção de mover parte do JavaScript para um “ser­vice work­er”. Eu men­cionei que o JavaScript com­pete por uma thread prin­ci­pal no nave­g­ador, mas isso é uma espé­cie de solução alter­na­ti­va que abre out­ro lugar para ser executada.

Exis­tem algu­mas com­pen­sações no que diz respeito ao armazena­men­to em cache e, dessa for­ma, o “ser­vice work­er” não pode aced­er ao chama­do DOM; ou seja, não poderá faz­er atu­al­iza­ções ou alter­ações necessárias. Se você vai mover o JavaScript para um “ser­vice work­er”, você real­mente pre­cisa de ter um desen­volve­dor que sai­ba o que está a fazer.

Recursos

• Otimizar o FID — web.dev
• Como mel­ho­rar a Veloci­dade da Pági­na do Iní­cio ao Fim — Ahrefs

Exis­tem muitas fer­ra­men­tas que você pode usar para tes­tar e mon­i­tor­izar CWV. Geral­mente, você pode quer­er ver os dados reais de cam­po, que é o que será medi­do na real­i­dade. Porém, os dados de lab­o­ratório são bem mais úteis para testes.

A difer­ença entre os dados de lab­o­ratório e de cam­po é que os dados de cam­po anal­isam usuários reais, condições de rede, dis­pos­i­tivos, armazena­men­to em cache, etc. Por out­ro lado, os dados de lab­o­ratório são tes­ta­dos con­sis­ten­te­mente com base nas mes­mas condições para tornar os resul­ta­dos do teste repetíveis.

Muitas dessas fer­ra­men­tas usam o Light­house como base para os testes de lab­o­ratório. A exceção é o Web­PageTest, emb­o­ra você tam­bém pos­sa exe­cu­tar testes do Light­house com ele. Os dados de cam­po são prove­nientes do CrUX.

Dados de campo

Exis­tem algu­mas fer­ra­men­tas adi­cionais que você pode usar para cole­tar os seus próprios dados de “Mon­i­tor­iza­ção Real de Usuários” (RUM) que fornecem feed­back mais ime­di­a­to sobre como as mel­ho­rias de veloci­dade afe­tam os usuários reais (em vez de depen­der ape­nas de testes de laboratório).

Dados de laboratório

O Page­Speed Insights é óti­mo para ver­i­ficar uma pági­na de cada vez, é cer­to, mas se você quis­er obter dados de lab­o­ratório e dados de cam­po em larga escala, a maneira mais fácil de obter isso é por meio de uma API. Você pode conec­tar-se facil­mente com as Fer­ra­men­tas para Web­mas­ters da Ahrefs (gra­tu­itas) ou o nos­so Site Audit, obten­do relatórios que expliquem o seu desempenho.

Observe que os dados do Core Web Vitals mostra­dos serão deter­mi­na­dos pelo agente do usuário que você sele­cionar para o ras­trea­men­to durante a própria configuração.

Eu, pes­soal­mente, tam­bém gos­to do relatório do Google Search Con­sole porque poderá ver os dados de cam­po de várias pági­nas de uma só vez. Con­tu­do, os dados estão um pouco atrasa­dos e em uma média de 28 dias, por­tan­to, as alter­ações podem levar algum tem­po para apare­cer no relatório.

Out­ra coisa que pode ser útil é que você pode encon­trar os pesos de pon­tu­ação do Light­house a qual­quer momen­to e ver as alter­ações históri­c­as. Isso pode dar uma boa ideia da razão pela qual as suas pon­tu­ações mudaram e onde é que o Google pode estar a dar mais importân­cia, ao lon­go do tempo.

Considerações finais

Não acho que os Core Web Vitals ten­ham muito impacto no SEO e, a menos que você seja extrema­mente lento, geral­mente não colo­co como pri­or­i­dade ​​cor­ri­gi-los. Se você quis­er argu­men­tar a favor de mel­ho­rias nos Core Web Vitals, acho que isso é difí­cil de faz­er para SEO.

No entan­to, você pode defend­er isso para a exper­iên­cia do usuário. Ou, tal como men­cionei no meu arti­go de veloci­dade da pági­na, as mel­ho­rias devem ajudá-lo a reg­is­tar mais dados nas suas anális­es, o que pode “pare­cer” um aumen­to. Você tam­bém pode defend­er mais con­ver­sões, pois há muitos estu­dos por aí que mostram isso (mas tam­bém pode ser resul­ta­do do reg­is­to de mais dados).

Aqui está out­ro pon­to chave: tra­bal­he com os seus desen­volve­dores; eles são os espe­cial­is­tas aqui. A veloci­dade da pági­na pode ser extrema­mente com­plexa. Se você estiv­er soz­in­ho, pode ser necessário con­tar com um plug-in ou com algum serviço (por exem­p­lo, WP Rock­et ou Autop­ti­mize) para lidar com isso.

As coisas ficarão mais fáceis à medi­da que novas tec­nolo­gias forem lançadas e muitas das platafor­mas, como o seu CMS, o seu CDN ou até mes­mo o seu nave­g­ador, assumem algu­mas das tare­fas de otimiza­ção. A min­ha pre­visão é que den­tro de alguns anos, a maio­r­ia dos web­sites nem terá que se pre­ocu­par muito, porque a maio­r­ia das otimiza­ções já serão tratadas automaticamente.

Muitas das platafor­mas já estão sendo lançadas ou tra­bal­han­do em coisas que o aju­darão de for­ma facilitada.

O Word­Press já está pré-car­regan­do a primeira imagem e está mon­tan­do uma equipa para tra­bal­har nos Core Web Vitals. A Cloud­flare já lançou muitas coisas que tornarão o seu web­site mais rápi­do, como Ear­ly Hints, Signed Exchanges e HTTP/3. Espero que essa tendên­cia con­tin­ue até que os pro­pri­etários de web­sites não pre­cisem mais de se pre­ocu­par em tra­bal­har nisso.

Como sem­pre, envie uma men­sagem no Twit­ter se tiv­er algu­ma pergunta.