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.
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.