Rendering gap

This health check detects large gaps between Time to First Byte (TTFB) and First Contentful Paint (FCP) based on real user data.

It highlights cases where the server responds quickly, but the browser takes significantly longer to render the first visible content.

Each todo represents a template where rendering is slower than expected for a specific device type.

About this check

When this check is triggered

You’ll see this check when:

  • The gap between TTFB and FCP is unusually large
  • The impact is visible in real user data (p75, p85, p90)
  • There are enough events to validate the pattern
  • The issue is consistent for a specific template

What you’ll see

Each todo includes:

  • Template
  • Device type (desktop, mobile, tablet)
  • The difference between TTFB and FCP

Example:

Reduce rendering time for product-page on mobile
The time to first contentful paint (FCP) for product-page on mobile is significantly higher than the time to first byte (TTFB).

Why this matters

A large rendering gap means:

  • The server is fast, but the frontend is slow
  • Users are looking at a blank screen
  • Core Web Vitals like FCP and LCP are negatively impacted

This typically points to render-blocking resources or main-thread work after the response.

How to fix it

Most rendering gaps are caused by:

  • Render-blocking CSS and JavaScript
  • Large or unoptimized CSS bundles
  • Synchronous JavaScript execution
  • Client-side rendering delays (hydration, frameworks)
  • Slow font loading
  • Heavy third-party scripts
  • Inefficient resource loading order

Possible causes and fixes:

1. Trim render-blocking resources

Reduce what blocks the first paint.

What to do

  • Defer or async non-critical JavaScript
  • Split large CSS and JS bundles, for example per template type and a general file
  • Load non-essential resources after FCP

What to check

  • without defer, async, or type="module"
  • Large blocking resources in the critical path

2. Optimize CSS delivery (carefully)

CSS is one of the biggest blockers of FCP.

What to do

  • Inline critical CSS for above-the-fold content
  • Load remaining CSS asynchronously
  • Remove unused CSS

Important considerations

  • Inlining too little CSS can cause layout shifts (CLS) after load
  • Frequent deployments with changing critical CSS can introduce instability
  • Always validate that the inlined CSS fully covers initial layout across different viewports

3. Avoid @import in CSS

Using @import inside stylesheets delays loading and blocks rendering by 32%.

What to check

  • Third-party stylesheets (e.g. font providers like Typekit)
  • Nested CSS imports

What to do

  • Change @import constructions into regular stylesheet links in your HTML
  • To enforce loading external stylesheets in parallel instead of chained requests

4. Fix resource loading order

The order of CSS and JavaScript has a direct impact on rendering.

What to check

  • Blocking scripts placed after stylesheets

Why this matters

If a blocking script appears after a stylesheet:

  • The browser waits for the CSS to fully download
  • Then executes the script
  • Rendering is delayed further

What to do

  • Avoid blocking scripts entirely where possible
  • Ensure scripts use defer, async, or type="module"
  • Keep the critical path minimal and predictable

5. Reduce client-side rendering cost

Frameworks can delay paint if too much work happens before rendering.

What to check

  • Hydration time
  • Large component trees
  • Blocking data fetching before render

What to do

  • Move work to the server where possible
  • Avoid blocking rendering on API calls
  • Use partial hydration or streaming

6. Optimize font loading

Fonts can delay text rendering.

What to do

  • Use font-display: swap
  • Preload critical fonts
  • Limit font weights and variants

Important considerations

  • Chrome holds paint when encountering preloaded fonts
  • Be sure to not preload too many fonts
  • Similarly, do not preload heavy font files like variable fonts

7. Audit third-party scripts

Third-party scripts often delay rendering.

What to check

  • Tag managers
  • Chat and on-site search widgets
  • Personalization tools doing synchronous XHR calls before FCP
  • A/B testing tools typically coming with anti-flicker scripts deliberately holding paint

What to do

  • When critical (like analytics), load them first things first, but ideally with an script[async] strategy
  • When noticeable (like above-the-fold A/B testing), embed its JS high up in your head section while also preconnecting to involved origins
  • Use an async or lazy loading strategy for other (non-critical) resources
  • Remove or dynamically embed unused integrations

8. Reduce main thread blocking

Even after TTFB, the browser may be busy executing JavaScript.

What to check

  • Long tasks in Chrome DevTools
  • Heavy JavaScript execution during initial load

What to do

  • Break up long tasks
  • Reduce bundle size
  • Avoid synchronous execution during initial render

Further debugging

How to approach this in RUMvision

  1. Open the todo
  2. Identify the template
  3. Compare:
    • TTFB (server time)
    • FCP (render time)
  4. Reproduce the issue:
    • Use Chrome DevTools → Performance panel
    • Look for blocking resources and long tasks
  5. Identify what delays rendering
  6. Apply fixes (usually frontend optimization)
  7. Monitor improvement over the next 7 days

Pro tip

Focus on:

  • Templates with high traffic
  • Mobile devices (CPU constraints make gaps worse)
  • Pages with heavy frameworks or third-party scripts

A large rendering gap highlights delays after the initial response. Optimizing what happens between TTFB and FCP often leads to the biggest improvements, but always evaluate TTFB alongside it.

Table of Contents