FCP (First Contentful Paint)

First Contentful Paint is het moment waarop de bezoeker voor het eerst iets van de pagina ziet. Niet een witte achtergrond, maar echte content: tekst, een afbeelding, een SVG of een canvas-element. De tijd loopt vanaf het moment dat de navigatie start.

De drempels die Google hanteert: 1,8 seconde of sneller is goed, tussen 1,8 en 3 seconde moet beter, boven 3 seconde is slecht. Net als bij de Core Web Vitals kijk je naar het 75e percentiel van echte bezoeken.

FCP is geen Core Web Vital en telt niet mee in de beoordeling in Search Console. Het is wel een diagnostische metric die je in CrUX, PageSpeed Insights en Lighthouse terugziet.

FCP vertelt je waar de vertraging zit. Een trage FCP betekent bijna altijd dat het probleem vóór het renderen ligt: een hoge TTFB, render-blocking CSS of JavaScript in de head, of webfonts die de tekst onzichtbaar houden.

Het gat tussen FCP en LCP is ook informatief. Is FCP snel en LCP traag, dan verschijnt de pagina wel, maar laat de grote productfoto of hero-banner op zich wachten. Dan kijk je naar de afbeelding zelf: formaat, prioriteit en of hij niet per ongeluk lazy geladen wordt. Zijn FCP en LCP allebei traag, dan begin je bij de server en de head van je HTML.

Voor de bezoeker is FCP het eerste teken dat er iets gebeurt. Een lege witte pagina voelt langer dan dezelfde tijd met een zichtbare header en navigatie.

In PageSpeed Insights zie je FCP bovenaan bij de field data uit CrUX, als je site genoeg verkeer heeft. Daaronder staat de lab-meting van Lighthouse. Die twee kunnen flink verschillen. De field data laten zien wat je bezoekers echt ervaren; de lab-meting is een gecontroleerde test die helpt bij het vinden van oorzaken.

Bij Magento begint het bij de TTFB. Zonder full page cache of Varnish duurt het genereren van een categoriepagina al snel te lang voordat er überhaupt HTML is. Daarna komt de frontend: Luma laadt veel CSS en RequireJS-modules. Hyvä levert één kleine Tailwind-stylesheet en Alpine.js, waardoor de browser veel sneller kan beginnen met renderen.

In Shopify zit de winst meestal in het thema en de apps. Scripts zonder defer of async in theme.liquid, apps die eigen CSS bovenaan injecteren en grote webfonts houden de eerste weergave tegen. Gebruik font-display: swap en laad alleen de font-gewichten die je echt gebruikt.

In Laravel met Blade of een SSR-frontend zorg je dat de server direct bruikbare HTML stuurt en dat Vite de CSS als één geminificeerd bestand levert. Bij client-side rendering wacht FCP op het JavaScript-bundle, en dat zie je direct terug in de cijfers.

Lees bij een trage FCP eerst de TTFB af. Is de TTFB al meer dan de helft van de FCP, dan heeft frontendwerk weinig zin zolang de server niet sneller is. Begin dan bij caching en hosting.

Optimaliseren op FCP in Lighthouse terwijl de field data iets anders zeggen. Een lab-test op een snelle machine zonder cookies is niet de bezoeker op 4G met een consentbanner. Kijk naar CrUX of je eigen RUM-data.

Ook vaak gezien: een spinner of skeleton-scherm dat FCP mooi laat lijken, terwijl de echte content veel later komt. FCP gaat dan omlaag, LCP niet.