FCP measures the time from when the browser starts navigating to when it renders the first piece of visible DOM content — text, an image, a canvas, or an SVG. It is the user's first confirmation that something is actually happening.
Before FCP fires, the screen is blank. A fast FCP dramatically reduces perceived wait time even if the full page takes longer to load.
How Witnes captures it
Witnes reads FCP from the browser's PerformancePaintTiming API — specifically
the first-contentful-paint entry returned by
performance.getEntriesByType('paint'). This is a standard browser measurement
emitted by the rendering engine, not estimated or approximated.
What good looks like
Witnes displays FCP as a raw number — it does not apply a Good / Needs Improvement / Poor label to FCP directly. The table below shows Google's Web Vitals reference thresholds as a guide:
| Range | Assessment |
|---|---|
| < 1.8 s | Good |
| 1.8 s – 3 s | Needs Improvement |
| > 3 s | Poor |
FCP vs LCP
FCP and LCP are often confused. The key difference:
- FCP — first anything renders. Even a tiny spinner or a loading text qualifies. It answers "is the page loading?".
- LCP — the largest content element renders. It answers "is the main content ready?".
A page can have a fast FCP (loading spinner appears at 300 ms) but a slow LCP (hero image finishes at 4 s). Both matter — FCP for perceived responsiveness, LCP for perceived completeness.