Progressive Rendering is the technique of sequentially rendering portions of a webpage in the server and streaming it to the client in parts without waiting for the whole page to rendered.

Note: The content of this post may be relevant to all types of servers but written within the context of a node.js server. The perf metrics are assumptive and may differ based on network bandwidth and latency.

To understand progressive rendering we must first understand how client side rendering and server side rendering work.

Client Side Rendering

Client side rendering is the technique in which the server sends a simple HTML without any content in the body and script tags in the head. This is what create-react-app builds output.

Typical page load behaviour in CSR —

1. Browser requests the server for HTML
2. Server sends HTML with script tags in head and no content in body
3. Browser parses the HTML and makes http requests to load the scripts
4. Once the scripts are loaded, the browser parses them and makes API requests and loads all the content asynchronously

Since the all the content starts loading only after loading the initial JavaScript, it takes a longer time to show any content on the page. If the user is on a slow network, the content is blocked for an even longer time due to lower bandwidth and higher latency.

Pros

1. Once the initial JavaScript is loaded, the content can be loaded asynchronously. We can load the critical content first and then load non-critical content later.
2. Server serves static HTML and initial load JavaScript bundles can be cached in the browsers which may benefit frequent users.

Cons

1. Initial load JavaScript blocks content load. The larger your bundle size is, the longer it will take to show content on the page.
2. API requests to load content have to travel all over the world to fetch data as they are not co-located with the browser location. This may take even longer in slower networks due to high latency and low bandwidth.
3. SEO scores take a huge hit since search engines don’t execute JavaScript (arguably) and only an empty page is indexed. This matters when you want your page to be public and searchable.

Server Side Rendering

Server side rendering is the technique in which the whole HTML is rendered on the server and sent to client. This is what Next.js or Gatsby (build time server render) does.

Typical page load behaviour in SSR —

1. Browser requests the server for HTML.
2. Server makes API requests (usually co-located) and renders the content in the server.
3. Once the page is ready, the server sends it to the browser.
4. The browser loads and parses the HTML and paints the content on the screen without waiting for the JavaScript bundle(s) to load.
5. Once the JavaScript bundle(s) are loaded, the browser hydrates interactivity to DOM elements, which is usually attaching event handlers and other interactive behaviours.

Since the APIs are usually co-located with the server, the content is loaded super fast (faster than CSR) and the HTML is sent to the browser. Initial JavaScript load doesn’t block content load as the HTML sent by the server already has the content.

Pros

1. Since the server serves HTML with content, neither the browser nor search engines have to depend on JavaScript for the content.
2. Content is not blocked by the time taken to load JavaScript bundle(s).
3. Page loads a lot faster than CSR.

Cons

1. The entire HTML has to be rendered on the server before sending it to the client. This means, even the non-critical content has to rendered on the server to before sending the response HTML to the client.

Progressive Rendering

Progressive Rendering (aka Progressive Server Side Rendering) is a technique in which once you render the critical content on the server, you start streaming it to the client without waiting for non-critical content. You then stream the non-critical content later once it’s rendered on the server. The browser starts to progressively render (paint) the HTML on the page as soon as a chunk for critical content is received. Non-critical content is then later rendered (paint) on the page when the browser receives it from the server.

Typical page load behaviour in PSSR —

1. Browser requests the server for HTML.
2. Server makes API requests (usually co-located) and renders the critical content first in the server and streams it to the browser.
3. The browser receives the chunk of HTML and renders (paints) it on the screen.
4. The server renders non-critical content after rendering critical content and streams it to the client.
5. The browser receives and renders (paints) the non-critical content later.
6. Once the entire page is loaded, the browser hydrates interactivity to DOM elements, which is usually attaching event handlers and other interactive behaviours.

Progressive rendering bridges the benefits of both CSR and SSR. Content is rendered quickly since the APIs are co-located in the server and at the same time, critical content can be rendered quickly without having to wait for non-critical content.

With Progressive Rendering, you can make your site load faster asynchronously without relying on JavaScript to load content.

The whole idea of progressive rendering depends on the concept of streaming HTML from the server to client. You can read more about it here.

You often get magnitudes of performance boost if you do PSSR right. Here’s an example of the same website rendered with SSR vs PSSR. (Assuming the site is loaded over a low bandwidth network with high latency).

To put things into perspective, perf profiling SSR vs PSSR gives a clear perf boost in how quickly content shows up in the page.

How to progressively render a page?

Node.js has this Readable API which will let you pipe a readable stream. An example code to stream HTML might look like this

router.get("/stream", async function(req, res, next) {
  res.status(200);
  res.type("text/html; charset=utf-8");

// myRendered renders the HTML content
const DOCTYPE = await myRendered.DOCTYPE();
  const openHTML = await myRendered.openHTML();
  const head = await myRendered.head();
  const openBody = await myRendered.openBody();

res.write(`${DOCTYPE}${openHTML}`);
  res.write(head);
  res.write(openBody);

const pageChunks = [
    myRendered.header,
    myRendered.criticalContentOpen,
    myRendered.nonCriticalContentOpen,
    myRendered.nonCriticalContentClose,
    myRendered.criticalContentClose,
    myRendered.closeBody,
    myRendered.closeHTML
  ];

const pageStream = new Readable({
    async read(size) {
      if (!pageChunks.length) {
        pageStream.push(null);
      } else {
        const chunkToRender = pageChunks.shift();
        const renderedChunk = await chunkToRender();
        pageStream.push(renderedChunk);
      }
    }
  });

// stream content as soon as they are rendered
pageStream.pipe(res);
});

The example for this website built with Express and vanilla JS is here —

https://github.com/flexdinesh/progressive-rendering

The idea is you predictably slice portions of your HTML content and stream it to the browser as soon as it is rendered.

Pros

1. Render on server but stream critical content to client without waiting for non-critical content.
2. Content is not blocked by the time taken to load JavaScript bundle(s).
3. Page loads a lot faster than both CSR and SSR.
4. Build fruitful user experiences even for users on slower networks.

Cons

1. The browser will hydrate the DOM and attach event listeners only after the whole page is loaded. Even though content shows up quickly, interactivity will be enabled only after non-critical content is loaded. (But showing up content a lot quicker is still a win).
2. There is no established framework for progressive rendering and is highly dependent on the web application and its limitations.

Tips for effective progressive rendering

• Load critical CSS in the head
• Using CSS grid for layouts removes the dependency on the order of how the content is streamed

That’s all folks.

Drop a comment below or start a conversation with the author in Twitter on what you think about this article.

Progressive Rendering — The Key to Faster Web was originally published in Thinkmill on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hands down console.log() was, is and will always be the greatest debugging tool of all time.

React team launched a new version of the React Dev Tools (v4) a few weeks ago and it’s fantabulous. It gives you debugging superpowers to navigate through your tree, trace data flow, spot weak links and optimise for perf.

There are two separate tabs (Components, Profiler) now as opposed to the old version which had only one React tab.

New Dev Tools has great many improvements over the old version. To highlight a few —

• 🏎 Faster
• 🎣 Hooks support
• 🧐 Advanced tree filter
• 🤠 Better search UX
• 👮‍♀️ Badges for HOCs
• 🎯 Remembers selection after page reload

Top 10 Features

Dev Tools can do a lot of things. We’re are not going to dive into the nitty gritty details of each and every feature. Instead we’ll take a look at the top 10 helpful features that help us save time and write better React code.

Components Tab

1. Live edit state/props
2. Search through tree
3. Advanced tree filter
4. Rendered by
5. Owners tree
6. Quick Navigation
7. Utils

Profiler Tab

1. Profile initial mount
2. Why did this render?
3. Rendered at

1. Live Edit State/Props

You can live edit the state and props of a component and instantly see the results in the page.

2. Search Through Tree

The search bar comes handy when you want to quickly find and jump to a component in the tree. Now that the Dev Tools can remember stuff the selected node is saved between reloads and you don’t have to repeat the action every time you reload the page.

3. Component Filter

Filter is a powerful feature to reduce visual noise and focus on what matters at the moment in a huge tree. You can filter with a variety of options like context, HOCs, host(DOM) nodes, component name, etc.

4. Rendered By

Rendered By is a list of owner/parent components that rendered the selected component. You can quickly jump to a parent component by selecting an entry from the list.

5. Owners Tree

Owners Tree gives you an eagle eye view of a particular component and its sub-tree and hides the rest of the component tree.

To enter into owners tree view, you have to double click a component in the tree.

6. Quick Navigation

Switching between Elements tab (browser dev tools) and Components tab (react dev tools) is pretty easy and the corresponding node is auto selected in these tabs.

To find the corresponding DOM node in the Elements tab, select the component and click the small eye icon on the right pane. It will take you to the Elements tab with the corresponding DOM node selected.

To find the corresponding React node from Elements tab, just select a node in Elements tab and click the Components tab. React Dev Tools will automatically select the corresponding component.

7. Utils

Components tab offers three small handy utils.

1. Suspend component
2. Inspect matching DOM element
3. Log component data to console

Suspend Component

You can easily switch between the waiting(loading) and resolved states of Suspense components.

Inspect matching DOM element

We already saw this in Quick Navigation. You can select a component and click the eye icon on the right pane to jump to its corresponding node in Elements tab to inspect it.

Log component data to console

This is a handy utility that logs the entire component meta data to the console. The log gives details like props, hooks, corresponding DOM nodes and the component file location in the file system.

To log component data to console, select the component and click the small bug icon in the right pane.

Intro to Profiler

The next three features are going to be about the Profiler. Before diving into them, we’ll take a look at how profiler works and the key metrics that are used during profiling.

Every profiling session has two important colour graphs —

1. Commit graph
2. Component graph

Commit Graph

Commit graph gives you a list of commits (whole tree) during the session. Each commit denotes a user activity or side-effect that triggered a render in the tree .You will see it coloured from orange to green with orange denoting the costliest (took most time) commit and green denoting the cheapest (took least time) commit.

Component Graph

Component graph gives you info on which component rendered during a single commit. You can select each commit from the commit graph to see its component graph. It is also colour coded with cost information —

1. Dark Grey — Component did not render but a part of its sub-tree rendered
2. Transparent Grey — Neither the component nor its subtree rendered

3. Coloured — Both the component and its entire subtree rendered

8. Profile Initial Mount

Initial mount and first render is usually a perf heavy op in most React applications. In older versions of Dev Tools, it was impossible to profile and audit the initial mount phase. But the latest version provides an option to profile and audit the initial mount.

9. Why Did This Render?

This is the most powerful feature of the Dev Tools yet and it tells you why a component rendered during a profiling session. A component might have rendered for one or many of these reasons —

1. Props changed
2. State changed
3. Hooks changed
4. Parent component rendered

You can profile an activity and see why a component rendered during the profiling session to spot weak links and prevent unnecessary renders in the tree.

Note: You have check this setting — “Record why each component rendered while profiling” to see this info in the right pane of the Profiler Tab.

10. Rendered At

Rendered At info on the right pane gives you two time metrics —

1. When exactly the component rendered during the profiling session
2. How long it took for the component to render during the profiling session

Eg. 2.2s for 2.3ms

Here, 2.2s means the component rendered at 2.2s(2200ms) from the start of the profiling session which is 0s. And 2.3ms is the amount of time it took for the component to render.

That’s all folks.

If you’re interested in exploring all the features, the React team has built a site just for that — Interactive Dev Tools.

Play around with Dev Tools and drop a comment below or start a conversation with the author in Twitter on what you think.

React Dev Tools — Debug Like a Ninja was originally published in Thinkmill on Medium, where people are continuing the conversation by highlighting and responding to this story.