Sebesség Szakszó

FCP (First Contentful Paint)

Szerző: · 8 perc olvasás · Frissítve:
FCP (First Contentful Paint) - Sebesség (szakszó) a tudástárban
FCP (First Contentful Paint) - Sebesség | eClick GEO-audit tudástár

Az FCP (First Contentful Paint) az az időpont, amikor a böngésző az oldal betöltésekor kirajzolja az első tartalmi elemet: egy szövegdarabot, képet vagy SVG-t. Az üres, fehér képernyő ekkor ér véget, tehát az FCP azt méri, mikor látja a látogató az első jelét annak, hogy az oldal működik.

Hogyan működik

A mérés a navigáció kezdetétől indul. A böngésző letölti a HTML-t, feldolgozza, majd megpróbál rajzolni. Az első rajzolás csak akkor történik meg, ha a DOM-ban van megjeleníthető tartalom, és nincs olyan erőforrás, ami blokkolja a renderelést.

Az FCP így két korábbi szakaszra épül. Az egyik a TTFB (Time to First Byte), vagyis az első bájt megérkezése a szerverről. A másik a fej-részben lévő CSS és JavaScript feldolgozása. Ha ezek közül bármelyik lassú, az FCP automatikusan csúszik. Egy render-blokkoló CSS-fájl önmagában több száz ezredmásodpercet tesz hozzá.

Küszöbértékek

A Google által használt határok mobilon, mezei adaton:

  • jó: 1,8 másodperc alatt
  • fejlesztendő: 1,8 és 3,0 másodperc között
  • gyenge: 3,0 másodperc felett

Az érték a 75. percentilis, tehát a látogatók háromnegyedének ennyinél gyorsabbnak kell lennie. A laborban mért PageSpeed-érték ennél gyakran kedvezőbb, mert ideális hálózatot és eszközt feltételez.

Mi a szerepe a keresőknek és az AI-nak

Az FCP nem tagja a Core Web Vitals hármasának, tehát közvetlen rangsoroló jel nem lesz belőle. Diagnosztikai értéke viszont nagy: megmutatja, hogy a lassúság a szerveren vagy a böngészőben keletkezik. A LCP szinte soha nem lehet jobb az FCP-nél, így a rossz FCP mindig magával rántja a fő metrikát is.

Az AI-crawlerek többsége nem futtat JavaScriptet, ezért náluk az FCP-t nem lehet értelmezni. Ami viszont az FCP-t rontja, az őket is bünteti: a lassú szerverválasz és a kliensoldali renderelés. Amit a böngésző csak később rajzol ki, azt egy nyelvi modell gyakran egyáltalán nem látja.

Röviden: az FCP a fehér képernyő vége, és a legjobb kiindulópont annak eldöntéséhez, hogy a szervert vagy a frontendet kell javítani.

Miért fontos

A látogató első benyomása

A fehér képernyő alatt a felhasználónak nincs visszajelzése. Nem tudja, hogy tölt-e az oldal, vagy elromlott valami. A hosszú FCP-nél mérhetően nő a visszafordulás, mobilnál különösen.

Diagnosztikai érték

Az FCP osztja ketté a betöltést. Ha az FCP nagy része a TTFB (Time to First Byte), akkor a szerveren, a hoszton vagy a gyorsítótárazásban van a baj. Ha a TTFB jó, de az FCP mégis lassú, akkor a fej-részben lévő CSS és JavaScript a felelős.

A riportokban ezt látjuk a leggyakrabban: 300 ms-os TTFB mellett 2,8 másodperces FCP. Ilyenkor nem a tárhelyet kell cserélni, hanem a render-blokkoló erőforrásokat kell rendbe tenni.

Hatás az LCP-re

A LCP rangsoroló jel. Mivel a legnagyobb elem nem rajzolódhat ki az első elem előtt, az FCP alsó korlátot ad az LCP-re. Aki az LCP-t akarja javítani, de nem nézi meg az FCP-t, gyakran rossz helyen keresi a problémát.

Üzleti következmény

Webshopnál a kategória- és termékoldal FCP-je közvetlenül érinti a bevételt. A magyar KKV-oldalak többségén a lassú FCP oka egy sor hozzáadott plugin-stíluslap és egy hozzájárulás előtt betöltő méréskód.

Kikre vonatkozik

Vonatkozik rá

  • Minden publikus HTML-oldal, ami böngészőben jelenik meg
  • Webshopok, ahol a kategória- és termékoldal betöltése a bevételt érinti
  • Landing oldalak és kampányoldalak, ahol drága a forgalom
  • Blogok és tudástárak, ahol a szöveg az első kirajzolt elem

Kevésbé vagy egyáltalán nem vonatkozik rá

  • API-végpontok és JSON-válaszok: nincs renderelés, nincs FCP
  • Belépés mögötti felületek: mérhető, de kereső nem látja, csak a használhatóság szempontjából számít
  • Staging és fejlesztői környezet: az itt mért érték labor-adat, a valós hálózatot nem tükrözi
  • PDF- és fájlletöltések: nem HTML-dokumentum

Natív mobilalkalmazásnál nem értelmezhető. Beágyazott webnézetnél viszont igen, ott a mérés a webnézet indulásától számít.

Hogyan ellenőrzöd

Mezei adat (valós felhasználók)

  1. Nyisd meg a PageSpeed Insights oldalt, és add meg az URL-t.
  2. Nézd a felső, „Felhasználói élmény" blokkot. Ez a CrUX adatbázisból jön.
  3. Az FCP sorban látod a 75. percentilist mobilra és asztalira külön.
  4. Ha nincs mezei adat, az oldalon kevés a forgalom. Ilyenkor csak labor-adatod lesz.

A Search Console Core Web Vitals jelentése az FCP-t nem mutatja, csak az LCP-t, az INP (Interaction to Next Paint)-t és a CLS (Cumulative Layout Shift)-t.

Labor-adat (saját mérés)

  1. Nyisd meg az oldalt Chrome-ban, inkognitóban, bővítmények nélkül.
  2. Indíts Lighthouse futtatást a devtools Lighthouse fülén, mobil profillal.
  3. A Metrics blokkban olvasd le az FCP-t.
  4. A Performance fülön vedd fel a betöltést. Az idővonalon az FCP külön jelölve van.
  5. A Network fülön nézd meg, mi tölt be az első rajzolás előtt.

Böngészőből, kód nélkül

A konzolba illesztve a PerformanceObserver azonnal megmondja az értéket. A pontos kódot a technikai példában találod.

Jó jel

  • FCP 1,8 másodperc alatt mobilon, mezei adaton
  • A TTFB az FCP-nek kevesebb mint a felét teszi ki
  • Az első rajzolás előtt legfeljebb egy-két CSS-kérés fut
  • A betűtípus nem tünteti el a szöveget (font-display: swap)

Rossz jel

  • FCP 3 másodperc felett
  • Az FCP és a TTFB között több mint 1 másodperc telik el
  • A head-ben több blokkoló <script> van defer nélkül
  • Az oldal teljes tartalma JavaScriptből épül fel
  • A süti-sáv szkriptje a legelső kérések között fut

Hogyan javítod

WordPress

  1. Telepíts oldal-cache bővítményt, ha még nincs. Ez a TTFB (Time to First Byte)-t csökkenti.
  2. Kapcsold be a CSS és JS késleltetett betöltését a cache-bővítmény optimalizálási fülén.
  3. A kritikus CSS-t generáltasd le, a többit töltsd be aszinkron módon.
  4. Nézd át a bővítménylistát. Minden aktív plugin saját stíluslapot tölthet minden oldalon.
  5. A betűtípusokat hosztold saját domainen, és állíts be font-display: swap értéket.
  6. A GTM-et és a méréskódokat tedd defer vagy késleltetett betöltésre.

Shopify

  1. Az admin felület Online Store > Themes > Edit code részén nézd át a theme.liquid head-jét.
  2. A nem kritikus alkalmazás-szkriptekre tegyél defer attribútumot.
  3. Távolítsd el azoknak az appoknak a maradék kódját, amiket már nem használsz.
  4. A Shopify CDN-jét használd a képekhez, ne külső tárhelyet.
  5. Kerüld a több betűtípus-család egyidejű betöltését.

Unas

  1. A sablonszerkesztőben nézd meg, milyen egyedi kód került a fejlécbe.
  2. A külső szkripteket (chat, hőtérkép, pixel) tedd az oldal aljára vagy késleltesd.
  3. A logót és a fejléc-képeket tömörítsd, WebP formátumban töltsd fel.
  4. Az egyedi CSS-t egy fájlba vond össze, ne több beszúrt blokkba.

Shoprenter

  1. A sablon fejlécében csökkentsd a külső hivatkozások számát.
  2. A saját CSS-t a beépített szerkesztőben kezeld, ne inline stílusokkal oldalanként.
  3. A marketing-szkripteket hozzájárulás után töltsd be.
  4. Kapcsold be a rendszer tömörítési és gyorsítótár-beállításait.

Egyedi fejlesztés

  1. Mérd meg a TTFB (Time to First Byte)-t curl-lel. Ha 600 ms felett van, előbb a szerveren dolgozz.
  2. Tedd a kritikus CSS-t inline a head-be, a maradékot töltsd be media="print" trükkel vagy preload-dal.
  3. Minden <script> kapjon defer vagy async attribútumot, kivéve amit tényleg blokkolnia kell.
  4. Használj <link rel="preconnect"> elemet a külső domainekre.
  5. Szerveroldali rendereléssel add ki a fő tartalmat HTML-ben. Ez a LCP-t és az AI-olvashatóságot is javítja.
  6. Kapcsold be a brotli tömörítést és állíts be CDN (tartalomszolgáltató hálózat)-t.

Gyakori hibák

  • A head-ben blokkoló JavaScript fut - a böngésző megáll, amíg letölti és lefuttatja, addig nincs rajzolás.
  • A teljes CSS egyetlen óriási fájlban érkezik - a fölött-a-hajtás tartalom is a teljes stíluslapra vár.
  • A méréskód a legelső kérés - a GTM vagy a pixel fontosabb helyet kap, mint a tartalom.
  • font-display beállítás nélküli webfont - a szöveg láthatatlan marad, amíg a betűtípus meg nem érkezik, így az első rajzolás csúszik.
  • Csak asztali mérés - a mobil FCP tipikusan a duplája, a valós felhasználók többsége ott van.
  • Kliensoldali renderelés SSR nélkül - a HTML üres váz, minden tartalom JavaScriptből jön, az első rajzolás csak a bundle lefutása után történik.
  • Az FCP javítása a TTFB megnézése nélkül - ha a szerver 1,5 másodpercig gondolkodik, a frontend-optimalizálás nem hoz eredményt.

Technikai példa

Az első rajzolás előtt blokkoló erőforrások a leggyakoribb okozók. Így néz ki a rossz és a jó head:

<!-- Rossz: minden blokkol -->
<head>
  <link rel="stylesheet" href="/css/app.css">
  <link rel="stylesheet" href="/css/plugin-a.css">
  <link rel="stylesheet" href="/css/plugin-b.css">
  <script src="/js/jquery.js"></script>
  <script src="https://www.googletagmanager.com/gtm.js?id=GTM-XXXX"></script>
</head>

<!-- Jó: kritikus CSS inline, a többi nem blokkol -->
<head>
  <style>body{margin:0;font-family:system-ui}.hero{min-height:60vh}</style>
  <link rel="preconnect" href="https://www.googletagmanager.com">
  <link rel="stylesheet" href="/css/app.css" media="print" onload="this.media='all'">
  <script src="/js/app.js" defer></script>
</head>

A media="print" trükk miatt a böngésző letölti a CSS-t, de nem várja meg a rajzolással. Az onload után a stíluslap élesedik.

Az aktuális FCP-t a konzolba illesztve olvashatod ki:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.name === 'first-contentful-paint') {
      console.log('FCP:', Math.round(entry.startTime), 'ms');
    }
  }
}).observe({ type: 'paint', buffered: true });

A szerveroldali részt curl-lel ellenőrzöd. Ha a time_starttransfer magas, előbb a TTFB (Time to First Byte)-vel kell foglalkozni:

curl -o /dev/null -s -w "connect: %{time_connect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n" https://pelda.hu/

Mit néz ebből a riport

Az audit a PageSpeed API-n keresztül lekéri az FCP-t mobilra, és a küszöbökhöz méri. Ha van mezei adat, azt használja, különben a labor-értéket. A riport a TTFB-vel együtt mutatja, így látszik, a lassulás a szerveren vagy a böngészőben keletkezik.

Gyakori kérdések

Rangsorol a Google az FCP alapján?
Közvetlenül nem. Az FCP nem tagja a Core Web Vitals hármasának, tehát nem rangsoroló jel. Viszont alsó korlátot ad az LCP-re, ami már az. Rossz FCP mellett jó LCP gyakorlatilag nem létezik.
Mennyi a jó FCP?
1,8 másodperc alatt jó, 1,8 és 3,0 között fejlesztendő, 3,0 felett gyenge. Ezek mobilra, a valós felhasználók 75. percentilisére vonatkoznak. Az asztali gépen mért érték általában sokkal kedvezőbb, ezért abból ne vonj le következtetést.
Miért más a PageSpeed értéke, mint amit a saját gépemen látok?
A PageSpeed labor-mérése lassított mobil profilt szimulál. A saját géped gyors, a kapcsolatod jó, a cache tele van. A mezei adat a valós látogatóktól jön, az a mérvadó, ha van belőle elég forgalom.
Elég a tárhelyet cserélni a jobb FCP-hez?
Csak akkor, ha a TTFB a szűk keresztmetszet. Mérd meg curl-lel: ha az első bájt 600 ms felett érkezik, a szerver a probléma. Ha a TTFB jó, de az FCP mégis 2 másodperc felett van, a head-ben lévő CSS és JavaScript a felelős.
Számít az FCP az AI-crawlereknek?
Közvetlenül nem, mert a legtöbb AI-crawler nem futtat JavaScriptet, így renderelés sem történik. Az okok viszont közösek: a lassú szerverválasz és a kliensoldali renderelés mindkettőt rontja. Amit a böngésző csak később rajzol ki, azt a nyelvi modell sokszor egyáltalán nem látja.

Források

Kapcsolódó fogalmak

A te oldaladon hogy áll a(z) „FCP (First Contentful Paint)”?

Futtass egy SEO-auditot: pontszám, fejlesztői ítélet, a leggyorsabb javítások, és minden tételhez bizonyíték.

Ingyenes SEO-audit indítása