Os tres Core Web Vitals en 2026

Google mide tres métricas de campo principais para a experiencia da páxina. Cada unha ten un limiar para o rendemento "Bo":

• Largest Contentful Paint (LCP) — tempo para renderizar o elemento visible máis grande. Bo: por baixo de 2,5 segundos.
• Interaction to Next Paint (INP) — capacidade de resposta a todas as interaccións do usuario (substituíu o FID en marzo de 2024). Bo: por baixo de 200 ms.
• Cumulative Layout Shift (CLS) — estabilidade visual durante a carga. Bo: por baixo de 0,1.

Un banner de consentimento que bloquea o renderizado, executa JavaScript pesado na carga ou inxecta cambios de deseño tardíos pode empuxar calquera destes á banda de "Precisa mellora" ou "Deficiente" — e Google usa datos de campo de 28 días de usuarios reais de Chrome, polo que os problemas transitorios convértense en sinais de clasificación persistentes.

Como os banners de consentimento prexudican ao LCP

O Largest Contentful Paint adoita activarse nunha imaxe principal ou titular. Varios patróns de consentimento o atrasan innecesariamente:

Scripts CMP que bloquean o renderizado

Cargar o CMP de forma sincrónica desde a cabeceira do documento detén a análise de HTML ata que o script se descarga e executa. Se o CMP está aloxado nun CDN lento ou con caché frío, podes engadir 200-800 ms ao LCP globalmente.

Banner que cobre o elemento principal

Se o banner de consentimento está posicionado como unha superposición modal que cobre o elemento LCP, os navegadores seguirán medindo o LCP desde o elemento cuberto. Non obstante, se o banner é o elemento pintado máis grande, convértese no candidato LCP — e se se renderiza mediante JavaScript despois da carga da páxina, o LCP é artificialmente alto.

Solución: carga asíncrona cun pequeno bootstrap en liña

Carga o CMP completo de forma asíncrona (`async` ou `defer`), cunha pequena script en liña só para a visualización inicial do banner. O obxectivo é un bootstrap de menos de 5 KB comprimido. A lóxica de comportamento completa, as listas de provedores e o chrome de IU poden cargarse de forma diferida despois do primeiro pintado.

Como os banners de consentimento prexudican ao INP

O Interaction to Next Paint mide o peor tempo de resposta en todos os clics, toques e pulsacións de teclas durante unha sesión. As interaccións de consentimento de cookies adoitan ser a primeira interacción que fai un usuario — polo que un botón Aceptar lento arruína a puntuación.

Traballo pesado ao aceptar

Moitos CMP executan traballo síncrono ao aceptar: cargando máis de 40 scripts de proveedores, escribindo en localStorage, disparando eventos de dataLayer, activando actualizacións do modo de consentimento de Google. Se isto supera os 200 ms, o INP sufre.

Solución: poñer o traballo en cola despois do pintado

Ao facer clic en Aceptar, oculta o banner inmediatamente e programa o traballo pesado con `requestIdleCallback` ou `setTimeout(0)`. O usuario ve o banner desaparecer instantaneamente; os scripts dos provedores cárganse en segundo plano sen bloquear a interacción.

Como os banners de consentimento prexudican ao CLS

O Cumulative Layout Shift rastrea o movemento visual inesperado. Os banners son unha fonte clásica de CLS cando se inxectan no DOM despois de que o contido se pintou.

Inxección tardía do banner

Se o banner aparece 800 ms despois do LCP, empuxa o contido cara abaixo e xera un desprazamento do deseño. Mesmo un banner pequeno pode activar unha puntuación CLS de 0,1 ou máis se afecta a unha gran parte da ventana de visualización.

Rerenderizados do widget de preferencias de cookies

Os widgets de preferencias do pé de páxina que cargan logotipos de provedores de forma asíncrona poden refluxar todo o pé de páxina varias veces, aumentando o CLS.

Solución: reservar espazo desde o principio

Usa CSS para reservar o espazo do banner desde o primeirísimo pintado — marcador de posición de altura fixa, `min-height` no pé de páxina, ou un banner fixo na parte inferior que non empuxa o contido. Os CMP modernos deberían ofrecer unha configuración sen CLS de forma predeterminada.

Google Consent Mode V2 e rendemento

O Consent Mode V2 permite que as etiquetas de Google se executen nun estado sen cookies antes do consentimento, pasando sinais mediante `gtag('consent', 'default', {...})`. Isto é excelente para a continuidade da medición, pero a biblioteca gtag.js en si é de 50-90 KB. Cárgaa de forma asíncrona e establece os valores predeterminados o antes posible para evitar condicións de carreira.

• Establece os valores predeterminados antes de cargar gtag — pon a chamada de consentimento predeterminada na cabeceira, antes do script gtag.js.
• Usa `analytics_storage: 'denied'` como predeterminado — minimiza os datos recollidos antes do consentimento.
• Actualiza ao aceptar mediante requestIdleCallback — evita bloquear o fío principal.

Medir o impacto do CMP nos Core Web Vitals

Non supoñas — mide. Usa estas ferramentas para cuantificar o impacto do teu banner:

• PageSpeed Insights — datos de campo do informe Chrome UX máis auditoría de laboratorio Lighthouse. Compara puntuacións con e sen o script CMP.
• Extensión Chrome Web Vitals — superposición LCP, INP, CLS en tempo real durante as probas locais.
• WebPageTest.org — vista de tira de película e cascada que mostra exactamente cando se renderiza o banner e o que bloquea.
• Informe Core Web Vitals de Search Console — datos de campo de 28 días agrupados por patrón de URL. Comproba se as páxinas de destino co teu banner puntúan de forma diferente ás páxinas sen banner.

Como FlexyConsent mantén a velocidade