---
title: "Rendering gap (Help Center / Health checks / Recommendations)"
ai_context: "Use this article for questions about the RUMvision Rendering Gap Health Check, large delays between Time to First Byte (TTFB) and First Contentful Paint (FCP), and identifying frontend rendering bottlenecks after the server response. It covers template- and device-specific rendering delays, p75/p85/p90 impact, render-blocking CSS and JavaScript, critical CSS, `@import`, resource loading order, hydration, client-side rendering, font loading, third-party scripts and main-thread blocking. Relevant for questions about blank-screen time, slow FCP despite fast TTFB, LCP impact, `defer`, `async`, `type=\"module\"`, critical-path optimization, partial hydration, streaming, font preloading, anti-flicker scripts, long tasks, mobile rendering performance and monitoring whether frontend changes reduce the TTFB-to-FCP gap over the following days."
canonical: "https://www.rumvision.com/help-center/health-checks/recommendations/rendering-gap/"
---

Breadcrumbs: [Home](https://www.rumvision.com/?format=md) > [Help Center](https://www.rumvision.com/help-center/?format=md) > [Health checks](https://www.rumvision.com/help-center/health-checks/?format=md) > [Recommendations](https://www.rumvision.com/help-center/health-checks/recommendations/?format=md) > Rendering gap

# 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%](https://www.rumvision.com/use-cases/32-percent-noticeable-win-for-vipio-visitors/?format=md).

#### 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.