# Evästebannerit ja Core Web Vitals: pidä LCP, CLS ja INP vihreinä

> Miten evästebannerit heikentävät LCP-, CLS- ja INP-arvoja ja miten sen korjaat: async-lataus, ei asettelun siirtymiä, viivästetty asetuskeskus ja kevyet käsittelijät.

Source: https://www.cookiesh.eu/fi/blog/cookie-banners-core-web-vitals  
Published: 2026-07-30

## Key takeaways

- Evästebanneri voi vaikuttaa kaikkiin kolmeen Core Web Vitals -mittariin: LCP:hen, CLS:ään ja INP:hen.
- Lataa suostumusskripti asynkronisesti ja pidä muut kuin välttämättömät tagit passiivisina, jotta banneri ei koskaan estä pääsisällön renderöintiä.
- Renderöi banneri kiinteänä päällyskerroksena tai varaa sille tila, jotta se ei koskaan siirrä sivun sisältöä.
- Pidä Hyväksy- ja Hylkää-käsittelijät kevyinä: päivitä käyttöliittymä ensin ja luovuta sitten vuoro pääsäikeelle ennen tagien lataamista.
- Testaa uudessa istunnossa alueelta, jolla banneri näytetään, sillä silloin sen suorituskykykustannus tulee esiin.

Evästebanneri voi heikentää kaikkia kolmea Core Web Vitals -mittaria: se voi viivästyttää Largest Contentful Paint -arvoa (LCP) tai itse muodostua LCP-elementiksi, siirtää sisältöä ja kasvattaa Cumulative Layout Shift -arvoa (CLS) sekä saada Hyväksy-painikkeen tuntumaan tahmealta, mikä näkyy Interaction to Next Paint -arvossa (INP). Korjauskeinot tunnetaan: lataa suostumusskripti asynkronisesti, renderöi banneri kiinteänä päällyskerroksena, viivästä toissijaista käyttöliittymää ja pidä klikkauskäsittelijät kevyinä.

## Miksi evästebannerit vaikuttavat Core Web Vitals -arvoihin?

Banneri on usein ensimmäinen asia, jonka uusi kävijä näkee, ja se rakentuu JavaScriptistä, CSS:stä ja tekstistä, jotka kilpailevat varsinaisen sisältösi kanssa kaistanleveydestä ja pääsäikeen ajasta. Core Web Vitals mittaa juuri tätä kilpailua, ja arvio tehdään todellisten sivulatausten 75. persentiilin perusteella.

| Mittari | Mitä se mittaa | ”Hyvä”-raja | Miten banneri voi heikentää sitä |
| --- | --- | --- | --- |
| LCP | Milloin suurin kuva tai tekstilohko renderöityy | Enintään 2,5 s | Renderöinnin estävä suostumusskripti tai banneri itse muodostuu suurimmaksi elementiksi |
| CLS | Kuinka paljon näkyvä sisältö liikkuu odottamatta | Enintään 0,1 | Sivun kulkuun lisätty banneri, joka työntää sisältöä alaspäin |
| INP | Kuinka nopeasti sivu reagoi klikkauksiin, napautuksiin ja näppäinpainalluksiin | Enintään 200 ms | Raskas työ Hyväksy- tai Hylkää-käsittelijässä |

INP korvasi First Input Delay -mittarin (FID) maaliskuussa 2024, ja sillä on merkitystä suostumuksen kannalta. FID mittasi vain viivettä ennen ensimmäisen vuorovaikutuksen käsittelyä; INP mittaa koko ajan mistä tahansa vuorovaikutuksesta seuraavaan ruudunpiirtoon, ja ”Hyväksy kaikki” on usein ensimmäinen asia, jota kävijä klikkaa.

## Miten estän suostumusskriptiä hidastamasta LCP:tä?

Lataa se `async`-määritteellä ja pidä se pienenä. Synkroninen skripti `<head>`-osiossa pysäyttää HTML-jäsentimen, kunnes skripti on ladattu ja suoritettu, mikä viivästyttää otsikkoasi ja hero-kuvaasi kaiken muun ohella.

```html
<head>
  <script src="https://consent.example.com/loader.js" async></script>

  <!-- Passiivinen, kunnes suostumusskripti aktivoi sen hyväksynnän jälkeen -->
  <script type="text/plain" data-consent="analytics"
          src="https://analytics.example.com/script.js"></script>
</head>
```

Asynkroninen lataus on turvallista, kun muut kuin välttämättömät tagit ovat tällä tavoin passiivisia: mitään ei suoriteta ennen kuin suostumusskripti sallii sen. Automaattisen eston (auto-blocking) menetelmien, jotka sieppaavat skriptit sitä mukaa kuin niitä lisätään, on yleensä suoriuduttava synkronisesti ennen muita skriptejä, mikä vie renderöintiaikaa. Oppaassamme [skriptien estämisestä suostumukseen asti](/fi/blog/block-scripts-until-consent) vertaillaan menetelmiä.

Toinen LCP-ansa on banneri itse. LCP raportoi suurimman kuvan tai tekstilohkon, joka piirretään näkymään ennen kuin kävijä on vuorovaikutuksessa sivun kanssa. Pienellä puhelimella pitkän kappaleen sisältävä banneri voi olla otsikkoasi suurempi, ja jos se piirtyy myöhään, myös LCP on myöhässä. Pidä ensimmäisen tason teksti tiiviinä, käytä järjestelmäfonttia, jotta banneri ei koskaan odota verkkofonttia, äläkä koskaan toimita banneria kuvana.

Bannerin viivästäminen ei auta: myöhään ilmestyvä banneri voi silti muodostua LCP-elementiksi, vain myöhemmin.

## Miten estän banneria aiheuttamasta asettelun siirtymiä?

Renderöi se kiinteänä päällyskerroksena. CLS laskee jo olemassa olevan sisällön liikkeet, joten sivun päälle ilmestyvä elementti, jolla on `position: fixed`, ei siirrä mitään. Klassinen virhe on `<body>`-elementin alkuun ensimmäisen piirron jälkeen lisätty palkki, joka työntää koko sivua alaspäin.

```css
.consent-banner {
  position: fixed;
  inset: auto 0 0 0; /* kiinnitetty alareunaan, dokumentin kulun ulkopuolelle */
  z-index: 1000;
  font: 1rem/1.5 system-ui, sans-serif; /* ei odotettavaa verkkofonttia */
  animation: consent-in 200ms ease-out;
}

@keyframes consent-in {
  from { transform: translateY(100%); }
}

@media (prefers-reduced-motion: reduce) {
  .consent-banner { animation: none; }
}
```

Jos käytät animaatiota, animoi `transform`- tai `opacity`-ominaisuutta. Ominaisuuksien `top`, `height` tai `margin` animointi muuttaa asettelua ja voi rekisteröityä siirtymiksi. Jos suunnittelusi todella vaatii sivun kulkuun sijoittuvan bannerin, varaa sille tila palvelimella renderöidyssä HTML:ssä. Tämä toimii hyvin vain, jos palvelin lukee suostumuseväste ja jättää tilan varaamatta palaaville kävijöille.

Suunnittele myös, mitä tapahtuu suostumuksen jälkeen. Siirtymät, jotka tapahtuvat 500 ms:n kuluessa klikkauksesta tai näppäinpainalluksesta, jätetään CLS:n ulkopuolelle, mutta muutamaa sekuntia myöhemmin latautuva mainospaikka, videoupotus tai chat-widget ei ole. Anna näille säilöille kiinteät mitat tai `aspect-ratio`-arvo.

## Miten bannerin käyttöliittymää voi viivästää vaarantamatta vaatimustenmukaisuutta?

Toimita ensimmäinen taso heti ja lataa asetuskeskus (preference center) tarvittaessa. Ensimmäinen taso on lyhyt viesti ja muutama painike; toinen taso kategoriavalitsimineen, toimittajaluetteloineen ja evästetaulukoineen on yleensä raskas osa.

Valintaa et saa viivästää. ”Hylkää kaikki” kuuluu ensimmäiselle tasolle yhtä näkyvästi kuin ”Hyväksy kaikki”. Joulukuussa 2021 Ranskan CNIL määräsi Googlelle 150 miljoonan euron ja Facebookille 60 miljoonan euron sakot, koska evästeistä kieltäytyminen oli vaikeampaa kuin niiden hyväksyminen. Lue lisää artikkeleista [evästebannerien pimeät mallit](/fi/blog/cookie-banner-dark-patterns) ja [evästebannerin suunnittelun parhaat käytännöt](/fi/blog/cookie-banner-design-best-practices).

## Miten Hyväksy ja Hylkää pysyvät nopeina INP:n kannalta?

Tee mahdollisimman vähän ennen seuraavaa piirtoa ja luovuta sitten vuoro. Hidas käsittelijä tyypillisesti kirjoittaa suostumusevästeen, lähettää suostumuslokin, päivittää Google Consent Moden ja lisää useita toimittajien skriptejä yhdessä pitkässä tehtävässä, jolloin painike näyttää jäätyneeltä.

```js
function yieldToMain() {
  if (globalThis.scheduler?.yield) return globalThis.scheduler.yield();
  return new Promise((resolve) => setTimeout(resolve, 0));
}

acceptButton.addEventListener('click', async () => {
  banner.remove();                                    // 1. näkyvä palaute ensin
  saveConsent({ analytics: true, marketing: true });  // 2. pieni ja synkroninen
  await yieldToMain();                                // 3. anna selaimen piirtää
  activateTags(['analytics', 'marketing']);           // 4. raskas työ myöhemmässä tehtävässä
});

customizeButton.addEventListener('click', async () => {
  customizeButton.setAttribute('aria-busy', 'true');
  const { openPreferences } = await import('./preference-center.js'); // ladataan tarvittaessa
  openPreferences();
});
```

Lähetä suostumusloki `navigator.sendBeacon()`-kutsulla, jotta verkkotyö ei koskaan pidättele vuorovaikutusta, ja aktivoi suuri määrä tageja erissä niin, että välissä luovutetaan vuoro. `scheduler.yield()` ei ole vielä kaikissa selaimissa, joten varakeino on mukana.

## Miten bannerin vaikutusta pitäisi testata?

Testaa ensin ensikertalaisena ja sitten palaavana kävijänä. Lighthousen kaltaiset laboratoriotyökalut aloittavat tyhjällä tallennustilalla, joten ne näkevät bannerin aina:

1. Avaa sivu uudessa selainprofiilissa alueelta, jolla banneri näytetään.
2. Aja Lighthouse tai PageSpeed Insights ja tarkista, mikä elementti raportoidaan LCP-elementiksi.
3. Tallenna jäljitys Chrome DevToolsin Performance-paneelissa, klikkaa ”Hyväksy kaikki” ja etsi klikkauksen jälkeisiä pitkiä tehtäviä.
4. Tarkista samasta jäljityksestä asettelun siirtymät bannerin ilmestyessä ja tagien latautumisen jälkeen.
5. Toista palaavana kävijänä, jonka suostumus on tallennettu, sillä silloin suoritetaan enemmän tageja.
6. Vertaa jälkikäteen kenttädataa Search Consolessa tai PageSpeed Insightsissa; se kattaa liukuvan 28 päivän jakson, joten muutokset näkyvät vähitellen.

## Yhteenveto

Suostumusbannerin ei tarvitse heikentää Core Web Vitals -arvojasi. Lataa se asynkronisesti, pidä se dokumentin kulun ulkopuolella, viivästä raskasta toista tasoa ja pidä klikkauskäsittelijät kevyinä, ja jätä silti jokainen valinta yhtä helpoksi tehdä. Cookieshin kaltaiset työkalut voivat hoitaa lataamisen puolen asynkronisella, gzip-pakattuna alle 5 kB:n latausskriptillä, joka tarjoillaan maailmanlaajuisesta edge-CDN:stä ja on suunniteltu välttämään asettelun siirtymiä.

*Tämä artikkeli on yleistä tietoa eikä oikeudellista neuvontaa. Kun teet omaa tilannettasi koskevia päätöksiä, käänny pätevän tietosuoja-asiantuntijan puoleen.*

## FAQ

### Parantaako bannerin piilottaminen Lighthouselta Core Web Vitals -tuloksiani?

Ei. Googlen Core Web Vitals -arvio perustuu todellisten Chrome-käyttäjien kenttädataan, ja moni heistä näkee bannerisi. Sen piilottaminen laboratoriotyökaluilta vain piilottaa ongelman sinulta, ja eri sivun tarjoaminen testityökaluille tekee diagnostiikastasi epäluotettavaa.

### Onko alapalkki vai keskelle avautuva modaali parempi suorituskyvyn kannalta?

Kumpikaan ei aiheuta asettelun siirtymiä, kun ne käyttävät kiinteää sijoittelua. Suuri modaali peittää enemmän näkymästä ja raportoidaan mobiilissa todennäköisemmin LCP-elementiksi, joten kompakti alapalkki on suorituskyvyn kannalta yleensä turvallisempi valinta, kunhan kaikki vaihtoehdot ovat siinä yhtä näkyvästi esillä.

### Pitäisikö Core Web Vitals mitata erikseen kävijöille, jotka ovat jo antaneet suostumuksensa?

Siitä on hyötyä. Palaavat kävijät ohittavat bannerin, mutta heillä suoritetaan enemmän tageja, joten heidän latautumis- ja reagointiprofiilinsa eroaa ensikertalaisten profiilista. Mittausten segmentointi kertoo, kumpi ryhmä kaipaa parannuksia, mutta muista, että todellisten käyttäjien seurantadatan (RUM) lähettäminen kolmannelle osapuolelle voi itsessään edellyttää suostumusta.

## Sources

- [web.dev: Web Vitals](https://web.dev/articles/vitals)
- [Directive 2002/58/EC (ePrivacy Directive), EUR-Lex](https://eur-lex.europa.eu/eli/dir/2002/58/oj)
- [EDPB Guidelines 05/2020 on consent](https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en)