Stop Vite Cold-Start White Screens: Show Real Resource Loading Progress Without DevTools

Vite’s “cold start” behavior can surface as a brief but noticeable white screen on the first page load. This is especially common in larger Vue applications (or apps with many routes and components) where multiple JavaScript and CSS assets must download and parse before the framework can render the initial UI. While the time is often short, it becomes more visible as the dependency graph grows.

Typically, developers confirm what is happening by opening browser DevTools and checking the Network tab. In some cases, that is not convenient, and the user experience can be improved by showing loading status directly in the page while resources are still being fetched and executed.

What causes the “white screen” on first load

The white screen generally occurs between two milestones:

  • Before the entry script and styles complete downloading.
  • Before the UI framework (Vue, React, etc.) mounts and paints.

During this window, the browser has not yet rendered meaningful content. The page is effectively waiting for Vite-delivered assets. Even when caching helps later loads, cold start is the moment when the app is most likely to appear unresponsive.

Why showing progress helps

A loading screen or progress indicator can reduce perceived latency and communicate that the app is actively loading. The key detail is that “progress” should be tied to actual resource loading rather than a fixed timer. When the UI reacts to real network activity, the experience feels more accurate and trustworthy.

Option A: Use a dedicated Vite dev-server progress plugin

A practical approach is to inject a progress indicator only during development, so developers can quickly diagnose and visualize what is happening during the Vite dev server cold start. One example is vite-plugin-white-screen-progress, which displays resource loading progress on the page.

Install

npm install vite-plugin-white-screen-progress@latest --save-dev --save-exact

Enable only in development

To ensure the plugin does not affect production builds, configure it to run only for the dev server:

// vite.config.js
import devServerWhiteScreenProgress from 'vite-plugin-white-screen-progress'

export default {
  plugins: [
    devServerWhiteScreenProgress(),
  ],
}

This keeps the development experience transparent while avoiding unexpected UI injection in production.

Option B: Implement resource-based progress with PerformanceObserver

For teams that prefer a custom solution, the core idea is to observe when the browser loads resources. A minimal implementation pattern uses PerformanceObserver to watch resource timing entries and update a visible indicator.

Conceptual implementation steps

  • Create (or reuse) a small progress UI element placed early in the page.
  • Start observing resource timing events.
  • Update progress as resources appear (and optionally as they complete).
  • Hide the loader once the app has mounted or once a “ready” signal is reached.

This approach aligns the loader behavior with actual asset activity, which is what users perceive as “real loading progress.”

Option C: Add a custom loading screen in index.html (works without plugins)

When the goal is simply to avoid a blank page, a static loading overlay can provide immediate feedback. This technique is straightforward:

  • Insert a fixed, full-screen loading element in index.html so it appears immediately.
  • Use CSS for a spinner and text.
  • Remove or fade it out once the app mounts.

Compared to progress-based solutions, this is less “accurate,” but it still eliminates the dead-air feeling of a white screen.

Option D: Address framework-level lazy loading with Suspense (where applicable)

For component-level asynchronous loading (such as lazy routes), React’s Suspense or similar patterns in other ecosystems can show a fallback UI while modules load. This solves a different problem than Vite’s cold start bundle timing, but it improves perceived responsiveness after the initial mount.

Targeted checklist to reduce cold-start pain

  • Test production via build and preview to verify cold start behavior matches expectations.
  • Check for 404s and unexpected asset paths in the Network tab.
  • Hard refresh when testing (cache issues can mask or exaggerate progress behavior).
  • Verify base paths (misconfigured base can delay or break asset loading).
  • iOS/Safari mitigation: if white screens appear on Safari, consider setting a modern but compatible build target such as es2019 in Vite configuration.

Practical guidance: For development visibility, a dev-only progress plugin helps pinpoint loading delays. For user-facing polish, a custom loading overlay in index.html prevents the blank screen during the initial asset download window.

Bottom line

Vite cold-start white screens are usually the result of waiting for entry scripts, styles, and dependent modules to download and execute before the framework can render. Showing a loader that reflects real resource loading, or at least provides immediate visual feedback, can significantly improve perceived performance. Developers can choose between a purpose-built Vite dev-server progress plugin, a custom PerformanceObserver-based progress implementation, or a simple HTML overlay, then combine approaches for the best outcome.

Share:

LinkedIn

Share
Copy link
URL has been copied successfully!


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Close filters
Products Search