FCP Above Target, When the Page Still Shows Nothing
FCP above target. That is the flag when a page takes longer than 1.8 seconds to paint its first content, and FCP stands for First Contentful Paint, the first moment the visitor sees anything real on the screen. Up to that moment the page has shown no text and no image, so every extra second of FCP looks to the visitor like a site that is not loading at all.
The gap in real reports gets wide fast. One record from July in our files shows a page that took 3.78 seconds to paint its first content on desktop and 4.06 seconds on mobile against the 1.8 second target, flagged high on both devices and costing six points on the desktop performance score and seven on mobile. Four seconds of empty screen is longer than most people will wait before they decide the site is broken and leave.
What FCP measures
First Contentful Paint is the moment the browser draws the first visible piece of content, a line of text, an image, or a heading, as opposed to the background colour of an empty page. It is measured from the start of the navigation, so every delay before that first draw counts against it. The report measures desktop and mobile separately, and the two can disagree, because the mobile pass runs on a throttled connection that mirrors a mid-range phone.
The target line is 1.8 seconds. Under it the page earns the full FCP credit, between 1.8 and 3 seconds it keeps part of that credit, and past 3 seconds the check stops contributing and the finding escalates to high, because at that point the screen has been empty long enough that many visitors have already decided the page is broken.
What a slow first paint really costs
The visitor cost of FCP is the most direct of all the load metrics, because it happens before anything else exists on the page. People judge a site in the first couple of seconds, and a screen that stays blank for three of them reads as a dead site, not a slow one. That distinction matters, a visitor who thinks the site is broken leaves, while a visitor who thinks it is merely slow may stay.
FCP carries the lightest credit of the load checks, six desktop points against twelve for LCP, and that weighting is fair, it only measures the first fragment of content. A first paint that misses the line by a little while the main content lands on time is a small miss. The catch is the ceiling, the main content cannot appear before the first content does, so a first paint past three seconds holds everything else back too, and the same report usually flags LCP as well.
Everything that happens before the first paint
The chain before that first draw has three links, and the report tells you which one is slow. The first is the server response, nothing can paint until the first bytes of HTML arrive, and when that leg drags the report flags TTFB as its own finding. The second is the HTML itself and the resources it asks for, a page that ships a wall of stylesheets and scripts ahead of its content makes the browser stop and fetch each one before it can draw anything. The third is the size of those files, because every blocking kilobyte adds time to the first paint.
The finding’s own watch note says where to look first, FCP improvements almost always follow directly from TTFB and render-blocking fixes. If the report shows TTFB over target next to FCP, fix the server response first, that is the root. If TTFB is fine, the delay lives in the stylesheets and scripts between the response and the first draw.
Unblocking the first paint
Inline the styles the first screen needs. The browser will not paint until it has the CSS for what is on screen, so the biggest lever is making that CSS arrive first and weigh less. WordPress sites usually have this built into a caching or optimisation plugin as critical CSS, which extracts the styles the first screen needs into the page head and loads the rest after. On a hand-built site the same idea is a short style block in the head followed by the full stylesheet, and in both cases the gain is bigger when the page is not shipping a whole framework stylesheet just to use a fraction of it.
Defer what does not belong in the head. A script without defer or async stops the browser from parsing the HTML while it downloads and runs, which parks the content the page needs to paint. Scripts that only power features below the fold should not be in the head at all, move them to the end of the body or give them defer so they download in the background and run after the page has parsed. On WordPress those scripts belong to the theme and your plugins, and a caching or optimisation plugin can set defer for the whole site, which is the dashboard version of this fix. The distinction from the JavaScript metric matters here, TBT punishes the long tasks scripts run, FCP punishes them for standing in the way of the first paint.
Compress the text, then check the server. Stylesheets and scripts are text, and compression shrinks them hard, so the blocking downloads finish sooner. On most shared WordPress hosting the switch lives in the control panel or a plugin rather than a config file, LiteSpeed hosts usually ship the LiteSpeed Cache plugin, which compresses the whole site out of the box, and a CDN layer such as Cloudflare compresses text and caches static files at the edge with no server changes at all. The nginx block below is the same fix where the server config is yours to edit, and a Content-Encoding header in the response shows the compression is actually being served.
# nginx, compress the text assets that sit ahead of first paint
gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;
gzip_min_length 1024;
If the same report flags TTFB, the compression is not the root, the server is. Fix the response time first, page caching at the origin, longer cache at the edge, and fewer redirects all shorten it, and the TTFB guide in this series walks that route in full.
Watching the first paint arrive
Run the test again after each change, FCP moves the moment the blocking weight drops. The report shows the value on every run, so the fall toward the 1.8 second line is visible immediately. The same fixes are live on this site, after we replaced our uncompressed fonts with the modern web format and removed a script library that was loading twice, first paint here measures 652 milliseconds on desktop and 384 on mobile, and this finding no longer appears in our own reports.
One benchmark puts the flag in perspective. The numbers behind the global analytics page tell the story, the average first paint runs about 1.5 seconds on desktop and 1.4 on mobile, both under the 1.8 target, while the slowest ten percent of pages average just under three seconds on desktop and around 2.7 on mobile. The same page tracks delivery too, and its Server Delivery gauges show why compression earns a place on the fix list, only 37 percent of tested sites serve Brotli and 17 percent GZIP, close to half send their text files uncompressed, and just 41 percent of responses come from a cache. The typical site clears first paint, so when a report names FCP the delay is real, and the fix is usually the same short list, critical CSS, deferred scripts, and compression.
