Progressive rendering for better web application performance

Understanding web page rendering concepts and measuring render performance with Chrome DevTools

It doesn’t matter how good your site is; if it takes too long to download, no one will wait to see it. If your site takes more than 3 seconds to load, there is a high probability that you will lose some of your visitors. But did you know that you can dramatically improve the load time of your web app using progressive rendering? Progressive rendering not only improves loading speed, but also solves some serious problems in client-side and server-side rendering methods. To better understand progressive rendering, let’s take a look at how client-side and server-side rendering works.

Client side rendering

Client Side Rendering (CSR) is a technique in which content is rendered in the browser using JavaScript. Instead of getting all the content from the HTML file itself, the server sends HTML with an empty body and script tags that contain links to JavaScript bundles that the browser will use to render the content. Now let’s see how the page is rendered on the client side:

  1. When the user navigates to the web page, a request is sent to get the HTML document.
  2. The server sends HTML code with empty body and script tags to load JS bundles.
  3. The browser parses HTML and sends HTTP requests to get JS bundles. At this time, the user sees either a piece of HTML content, a blank page, or a loading indicator.
  4. Only after the main JS bundle is received and rendered, the user sees real, meaningful content.

In the CSR, after the JS is loaded, the content will be loaded asynchronously. We can load critical content first and then non-essential content.

Client side rendering

CSR has a slight advantage by caching loaded JS bundles and static HTML, so navigation between pages becomes very fast. However, in CSR, the content starts loading only after the entire JavaScript bundle has been executed, and users have to sit back, just watching a blank screen without understanding what is happening. As the size of the bundle grows, users will have to wait longer and longer before they see anything meaningful or start using the page. But what if we can render content independently of the JS bundle? This is where Server Side Rendering (SSR) comes in handy!

Server side rendering

When rendering on the server side, the HTML is rendered on the server and sent to the client. The content that we need to display on the screen becomes available immediately after the HTML is parsed; hence, primary rendering of content is faster than CSR. Now, let’s see how SSR works:

  1. The browser requests HTML from the server.
  2. The server makes API requests and renders HTML content on its side.
  3. The compiled HTML is sent to the browser.
  4. Once the browser downloads and parses the HTML, the web application becomes available to the end user without waiting for the JS bundles to load.
  5. The browser downloads and runs JS bundles to make the page interactive.

Since the API is usually hosted on a server and the source JavaScript does not block content, SSR loads the source content very quickly.

Server rendering

Although we get fast rendering of the content, the page will not be interactive until we load and execute the JS.

We can deal with the disadvantages of CSR with SSR. But other serious flaws remain, such as rendering critical and non-critical content before sending it to the client. I know what you are thinking now. Is there an approach where we can combine both mentioned methods, right? I have good news for you! By using progressive rendering, you combine the benefits of CSR and SSR. Now let’s take a look at how we can enhance your customer experience with progressive rendering techniques.

Server-side progressive rendering

“Progressive Server-Side Rendering: The key to speeding up a web page is the method of sequentially rendering portions of a web page on the server side and sending them to the client piece by piece, without waiting for the entire page to render.”

Progressive Server Side Rendering (PSSR) is based on the concept of HTML streaming. PSSR breaks pages into meaningful components using code splitting. These parts of the page are controlled by different scripts, and now we have the ability to do hydration independently. Let’s see how PSSR works:

  1. The browser requests the HTML code from the server.
  2. The server makes API requests and first renders the critical content and then sends it to the client.
  3. The browser parses the HTML and displays it on the screen.
  4. The server renders non-critical content and passes it to the browser.
  5. The browser then parses and displays non-critical content.
  6. Meanwhile, JS bundles are loaded and executed in the background, and the browser passes interactivity to the DOM elements.

PSSR improves the performance of your web application by fetching and rendering page components in a parallel and preemptive manner. This approach is known as the progressive hydration method. Features of the progressive hydration method:

  • The component is not rendered until it appears in the field of view or is needed for user interaction.
  • Loading content on user interaction (scrolling) – much faster than CSR or SSR
  • Testing shows that this can shorten the time until the first interactive element appears.
  • The experience is better even with slow connections.

In addition, you can use a critical rendering path approach with PSSR to further optimize your application’s performance.

Critical Rendering Steps

Optimizing critical rendering steps refers to prioritizing the location of content that is related to the user’s current activity. The browser does a lot of behind-the-scenes work to make the page experience better. Critical rendering steps are the immediate steps between receiving the HTML, CSS, and JS and the processing required to convert them to visible pixels.

You can shorten the initial render time of your web application by optimizing critical rendering steps

Since you now have a good understanding of client, server, and progressive rendering, you are probably wondering if there is a way to gauge rendering performance. The answer is yes! Chrome DevTools provides a separate tab for monitoring and evaluating rendering performance. Let’s see how we can use it.

Performance analysis with Chrome DevTools

Even in a small app, a lot of rendering is done under the hood. The Rendering tab in Chrome DevTools can be used to identify rendering issues in JavaScript applications.

Tool Paint flashing

As the interface becomes more feature-rich and complex, it is vital to consider ways to optimize the user experience by reducing both load time and critical path of components. Rendering content to the screen is one of the most expensive processes. To visualize this process, you can use the handy Paint Flashing tool available on the Rendering tab.

The current rendering areas will be highlighted in green if this option is enabled in Chrome. If you see areas that you didn’t intend to render, you can dig a little deeper.

Scrolling performance issues in Chrome DevTools

Scrolling performance issues is another handy tool that you can use to spot any performance issues while scrolling through the page. When this option is enabled, it hangs the label “Repaints on scroll” on the components and highlights in green those components that are rendered when the page is scrolled.

By tracking these performance issues, you can ensure that your web application gives your users the best possible experience.

Conclusion

When developing a web application, it is very important to understand the basic principles of rendering. This knowledge will help you optimize the performance of your web page. By statistics, a one second delay in page load will lower your conversion rate by 7%. On the other hand, long download times can have a devastating effect on app conversion rates. In this article, I’ve covered three rendering techniques and explained why server-side progressive rendering has more advantages over the other two, and how it helps improve the performance of your web application.

Similar Posts

Leave a Reply

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