Developers building web applications today need to be aware of the initial page load and interaction times of their applications. Two performance goals of building an application is minimizing the First Meaningful Paint and First Interactive. Modern JavaScript development today makes use of tools to minify, transpile, optimize, and bundle JavaScript code so applications load and run faster — but for larger applications there is also the issue of mounting too many components at once on the client-side which can create a bad experience for the user.

React does have some problems mounting large component trees, so I’ve been using a HOC to help defer the rendering to the next animation frame. It’s helped a lot with perceived performance… (View full thread on GitHub).

There are benefits to both client-side and server-side rendering, but an approach that I think will become more popular is a combination of them which some call Progressive Booting or Loading.

The goal is to quickly get some version of the initial page downloaded and displayed to the user, but then also run the necessary JavaScript code so that the user can interact with the important parts of the page, while lazy-loading the rest in the background. Mounting a large number of components on page load can therefore seriously degrade performance, especially if the user needs to wait 4+ seconds to start scrolling or interacting with the page.

This is what the PRPL pattern tries to emphasize:

Push critical resources for the initial route. Render the initial route. Pre-cache remaining routes. Lazy-load everything else.

The idea is to basically load the structure or shell of your application with some JavaScript code so the user is able to interact with the page, and then lazy-load the other components of the page. This will provide a better user experience while speeding up initial load times.

Image source page here.

Most popular frameworks today mount components onto the page synchronously which blocks the main thread.

In WebKit the process of resolving the style and creating a renderer is called “attachment” […] Attachment is synchronous, node insertion to the DOM tree calls the new node “attach” method. — Paul Irish and Tali Garsiel

Aside from the common techniques developers have been using to speed up JavaScript load/parse/execution times such as code splitting (fancier: route-based chunking), asynchronous loading, streams, minification, caching, and bundling, something that has been gaining traction over the last several months is requestIdleCallback.

The developers working on the leading frameworks have been working on incorporating this into the core framework code so that it can be easier for other developers to mount components with whatever priority they see fit.

Facebook recently released React v16, where one it’s new features is the implementation of Fiber which improved upon the reconciler algorithm.

Perhaps the most exciting area we’re working on is async rendering — a strategy for cooperatively scheduling rendering work by periodically yielding execution to the browser. The upshot is that, with async rendering, apps are more responsive because React avoids blocking the main thread.

Evan You also tried something similar for Vue.js async components:

Paul Lewis wrote about a year ago on his blog:

I’d love to see is libraries and frameworks adopting a Progressive Booting model, especially as we ship more code to our users. Not every component is special, and the developer should be given controls to decide how booting happens!

Looks like it’ll start becoming more common for developers to have full control, within the bounds of their framework, to prioritize what components are important and should load immediately while others wait in order to provide a better experience for the user.