In one paragraph
First Contentful Paint too slow means the page took longer than the configured target to render its first eligible text or graphic. Diagnose the work before that first visible content: document delivery, render-blocking resources, JavaScript, and fonts. Improve the dominant delay without introducing unstyled flashes or layout shifts, and confirm that the main content also appears promptly.
Why it matters
FCP marks the first eligible contentful paint rather than completion of the page. A logo appearing quickly while the main article remains absent is not a complete loading success. Use FCP alongside LCP and the actual visual sequence.
It is a diagnostic metric, not one of the current Core Web Vitals. Good FCP is generally 1.8 seconds or less, with values above 3 seconds poor. Field assessments use distributions such as the 75th percentile, rather than treating one laboratory request as the experience of every visitor.
Server response, redirects, network setup, blocking CSS, and client-side rendering can all affect the timing. A cold mobile run and a warm desktop browser can differ substantially even without a code change.
How WebAuditOS evaluates this finding
The supplied check reads first-contentful-paint during a sampled Chromium load at a 390×844 viewport using its documented mobile network and four-times CPU slowdown. Up to 1.8 seconds passes; over 1.8 through 3 seconds warns; over 3 seconds fails at the documented low-severity level. Pages not rendered or not measured under that profile are not graded.
It is a sampled laboratory observation, not real-user percentile data. Missing results are not passes. Compare repeated runs and equivalent conditions before attributing a small timing movement to a specific deployment.
How to fix it
- Record the affected template on a cold mobile-style load. In the performance trace, identify the period before FCP and the resources or tasks that occupy it. Check the rendered result, not just the number.
- If document delivery dominates, inspect server timing and connection costs before optimising tiny CSS fragments. Cache appropriate public responses and profile slow rendering paths without risking shared-cache personal data exposure.
- Reduce genuinely blocking CSS. Remove unused styles where safe, split by actual route needs, and consider build-generated critical styles for the first view. Do not blindly combine every file or defer the only stylesheet needed to render the page correctly.
- Review synchronous scripts in the head. An external classic script that can safely wait may use defer:
<script src="/assets/app.js" defer></script>Test dependencies and ordering. An inline script immediately following that element will not wait for the deferred script merely because it appears later in the source.
- Keep text visible during font loading with a suitable font-display strategy. Match fallback metrics to avoid trading a blank screen for a disruptive reflow. Preload only fonts needed early, with correct resource and cross-origin settings where applicable.
- Put important public content in the initial response when practical. Server rendering or static generation can avoid waiting for a large client bundle and an additional data fetch, but their server cost and caching require design rather than a universal toggle.
- Remove unnecessary navigation redirects and link directly to intended final URLs. Compare the full navigation timing with the scanner's individual diagnostics so setup time is not mistaken for pure application execution.
- Test rendering, interaction, LCP, and CLS after each meaningful change. Rescan the page and use field data where available to confirm the improvement across real devices.
What the fix can break
Asynchronously loading necessary styles without a correct critical fallback can produce a flash of unstyled content and later movement. A lower FCP is not a benefit if the visitor first sees an unusable page.
Changing script order can break configuration objects, widgets, and inline dependants. Test forms and navigation, not merely a screenshot.
Aggressive resource preloading can compete with CSS or the LCP image. Add priorities based on a trace, not by marking every asset as urgent. Keep public content and accessibility intact when simplifying the first render.
Questions
Is FCP a Core Web Vital?
No. It is useful for loading diagnosis. Current Core Web Vitals use LCP, INP, and CLS for their respective outcomes.
Why is desktop fast while the scan is slow?
The documented run uses a mobile viewport and throttled conditions with a cold-load perspective. Compare like-for-like tests.
Can FCP improve while the page still feels slow?
Yes. The first small element may appear earlier while main content or interaction remains delayed. Check LCP and actual usability too.
Which related checks help?
Review LCP, stylesheets, and the Core Web Vitals guide.