Progressive Rendering for Better Web App Performance

Understanding the Concepts Behind Page Rendering and Measuring Rendering Performance using Chrome DevToolsIt doesn’t matter how good your site is; if it takes too long to load, no one will wait to see it.If your site takes more than 3 seconds to load, …

Understanding the Concepts Behind Page Rendering and Measuring Rendering Performance using Chrome DevTools

It doesn’t matter how good your site is; if it takes too long to load, no one will wait to see it.

If your site takes more than 3 seconds to load, there is a good chance that you would lose nearly half of your visitors.

But did you know that you could improve the page load time of your web application drastically by using progressive rendering?

Progressive Rendering has not only increased the page load speed but has also addressed some major issues in Client-side Rendering and server-side rendering methods. To get a better understanding of Progressive Rendering, let’s see how Client-side and Server-side Rendering works.

Client-Side Rendering

Client-side rendering or CSR is a technique where content is rendered in the browser using JavaScript. Instead of getting all the content from the HTML file itself, the server sends the HTML with an empty body and script tags, including JavaScript bundles in the head, through which the browser can render the content itself.

Now let’s take a look at how client-side page rendering happens:

  1. When the user navigates to a web page, the initial request to get the HTML document is fired.
  2. The server sends an HTML with script tags to download the JS bundle with an empty body.
  3. The browser parses the HTML and makes HTTP requests to fetch the JS bundle. The user only sees the HTML shell’s partial content, either a blank page or a loading indicator.
  4. Only after the main JS bundle is fetched and rendered the user see the real, meaningful content.
In CSR, once the initial JS is loaded, the content can be loaded asynchronously. We can load the critical content first & the non-critical content later.
Client-side rendering

CSR can benefit users by caching the initial loaded JS bundles and static HTML in the browser, so the navigation between the pages becomes super fast.

However, in CSR, content starts loading only after the entire JavaScript bundle finishes executing. Until then, users have to sit duck, just watching a blank screen without an update on what’s happening.

As the bundle size increases, users will have to wait more and more before seeing anything meaningful or starting using the page.

What if we can render the content on the browser without depending on the JS bundle? This is where server-side rendering comes to the rescue!

Server-Side Rendering

In Server-side rendering, the full HTML is rendered on the server and sent to the client. The content we need to display on the screen is available as soon as the HTML is parsed; hence the first content paint loads faster than the CSR.

Now let’s understand how the SSR works:

  1. The browser requests the HTML from the server.
  2. The server makes API requests and renders the HTML content on itself.
  3. The compiled HTML is then sent to the browser.
  4. Once the browser loads and parsers the HTML, the web app is made available to the end-user without waiting for the JS bundles to load.
  5. Then the browser downloads and executes the JS bundles to make the page interactive.
Since the APIs are usually co-located within the server, and initial JavaScript doesn’t block the content, in SSR, the initial content comparatively loads super fast.
Server-side rendering

In SSR, though we get a fast first contentful paint, the page isn’t interactive until we download the JS bundles and execute them on the browser.

We can indeed overcome the drawbacks of CSR using SSR. But still, there are some major drawbacks like rendering both critical and non-critical content before sending it to the client.

I know what you’re thinking now 😃 How cool it is if there’s an approach where we can mix both the techniques mentioned above, right? I have good news for you! Using Progressive Rendering, you can bridge the benefits of both CSR and SSR.

Now let’s look at how we can give your users a better user experience using the progressive rending technique.

Progressive Server-Side Rendering

“Progressive Server-Side Rendering — the key to a faster web page is the technique of sequentially rendering parts of the web page on the server-side and send it to the client in portions without waiting for the entire page to be rendered.”

Progressive Server-Side Rendering (PSSR) is based on the concept of HTML streaming. PSSR breaks the pages into meaningful components using code splitting. Those pieces of the page are controlled by a separate script, and now we have the opportunity to hydrate them independently based on some priority that we’ve determined earlier.

Let’s take a quick look at how the PSSR works:

  1. The browser requests the server for the HTML.
  2. The server makes API requests and renders the critical content first, and sends it to the client.
  3. The browser parses the HTML and paints it on the screen.
  4. The server renders the non-critical content and streams it to the browser.
  5. The browser then parses and paints the non-critical content.
  6. In the meantime, JS bundles are downloaded and executed in the background, and the browser hydrates interactivity to DOM elements.
PSSR improves your web app’s performance by fetching & rendering the page components in a parallel & prioritized manner. This approach is known as the Progressive Hydration method.

This Progressive hydration method leads to:

  • Defer hydration of a component until it comes into view or is needed for user interaction.
  • Load content on user interaction(scroll) — a lot faster than CSR and SSR
  • Testing shows this can improve TTI.
  • A better user experience even in the slow networks.

In addition to that, you can use the critical rendering path approach with PSSR to optimize your application’s performance even more.

Critical Rendering Path

Optimization of critical rendering path refers to prioritizing content displays that link to the current user activity. The browser does lots of work behind the scenes to deliver a fast web experience to the user. Critical rendering path is the immediate steps between receiving HTML, CSS, and JS bytes and the processing required to turn them into rendered pixels.

Optimization of critical rendering path

You can improve the time to first render your web app by optimizing the critical rendering path.

Since now you have a good understanding of Client-side, Server-side, and Progressive Rendering, you must be thinking that is there a way to evaluate these rendering performances. The answer is YES!!

Chrome DevTools provides a separate tab to monitor and evaluate rendering performance, and let’s see how we can use it.

Tip: Share your React components between projects using Bit (Github).

Bit makes it simple to author, document, and share independent components. Use it to maximize code reuse, speed-up delivery, and build apps that scale.

Bit supports Node, TypeScript, React, Vue, Angular, and more.

Exploring shared components on Bit.dev

Performance Analysis using Chrome DevTools

Even in a small application, there’s lots of rendering going behind the scene. The Rendering tab in Chrome DevTools can be used to spot out rendering related issues in JavaScript applications.

  • Chrome DevTool’s Paint flashing Tool

As the frontend becomes more feature-rich and complex, it is vital to consider ways to optimize user experience by enhancing both the loading time and components’ critical path. Pixel painting on the screen is one of the most costly processes. You can use Paint Flashing, a handy tool available in the Chrome DevTools Rendering tab, to visualize this.

Paint Flashing option in the Rendering tab

The screen will have green squares around the currently rendering areas, with this option switched on in Chrome. If you see places you didn’t plan to paint, you can dig in a little further.

Paint Flashing on Medium Home Page
  • Scrolling performance issues in Chrome DevTools

Scrolling performance issues in DevTools is another convenient tool that you can use to identify any issue regarding scrolling performance. When this option is selected, it shows the label ‘Repaints on scroll’ and highlights the which renders in scrolling in green.

Scrolling performance issue in Dribble Home page

By tracking down these kinds of performance issues, you can ensure that your web app provides your users’ best possible experience.

Final Thoughts

When developing a web app, understanding the basic concepts of how the rendering of a web app works, will help you to optimize your web page’s performance.

Based on the statistics, a one-second delay in page load time will drop your conversion rate by 7%.

On the other hand, lengthy loading times can have a devastating impact on the app’s conversion rates.

In this article, I have mentioned three rendering methods and explained why progressive server-side rendering has more advantages over the other two methods and how it helps enhance your web app’s performance.

Thank You for reading!! Feel free to hit me up with your thoughts in the comment section below 👇.

Learn More


Progressive Rendering for Better Web App Performance was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.


Print Share Comment Cite Upload Translate
CITATION GOES HERE CITATION GOES HERE
Select a language: