Render-Blocking JavaScript Files in the Node-RED Editor (min.js Bundles Delaying UI Load)

Core Development
1

Hi Team,

While profiling the Node-RED editor (workflow builder) using Chrome DevTools Performance Recorder, I noticed that several minified JavaScript files (min.js) are being loaded in a render-blocking manner. This significantly delays the editor from becoming interactive.

I want to understand whether this is expected behavior or if there are recommended optimization paths for reducing render-blocking scripts in the Node-RED editor.

Summary of the Issue

  • During page load, multiple JavaScript bundles appear in red in the network waterfall, indicating they are render-blocking.
  • These scripts must fully download, parse, and execute before the UI can render.
  • As a result, the Largest Contentful Paint (LCP) is delayed.
  • Estimated render-blocking impact (from DevTools): ~3.5 seconds.

Files Observed as Render-Blocking

Examples of files flagged by the performance trace:

  • vendor.js
  • red-debug.min.js
  • main.min.js
  • dynamic.min.js
  • mermaid.min.js
  • Additional Node-RED editor JS bundles (jsonata, infotips, node definitions, etc.)

The waterfall shows all of these downloading and executing before the editor renders.

Evidence

The screenshot attached shows:

  • All red-colored network requests are considered render-blocking.
  • DevTools recommendations show an estimated render-blocking savings of 3.56s.
  • Font loading (e.g., NunitoSans.ttf) also contributes additional blocking time.

What I Want to Understand

  1. Is it expected that so many editor scripts load synchronously?
    Does Node-RED rely on blocking script execution order to initialize the editor?
  2. Is there an existing recommendation for optimizing script loading?
    For example:
  • using defer instead of synchronous <script> tags
  • splitting larger bundles
  • lazy-loading editor modules
  • reducing up-front JS parsing cost
  1. Has this been discussed or optimized in recent versions?
    Are there any active efforts or guidance for minimizing render-blocking on editor startup?

Request for Guidance

Any insights on:

  • why Node-RED ships these JS bundles in a render-blocking manner,
  • whether this is necessary for correct editor initialization, and
  • whether there are optimizations I can contribute or configure,

would be very helpful.

I can also share the full performance trace if needed.

image
image2880Ă—1258 453 KB

2 Likes
2

This is just how it is; no real consideration has been made for making anything async. There may be some small gains possible (mermaid could likely be handled async), but I suspect there are also lots of base line assumptions about what has been loaded before the editor allows for any proper interaction.

4 Likes