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.
Now let’s take a look at how client-side page rendering happens:
- When the user navigates to a web page, the initial request to get the HTML document is fired.
- The server sends an HTML with script tags to download the JS bundle with an empty body.
- 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.
- 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.
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.
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!
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:
- The browser requests the HTML from the server.
- The server makes API requests and renders the HTML content on itself.
- The compiled HTML is then sent to the browser.
- 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.
- Then the browser downloads and executes the JS bundles to make the page interactive.
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:
- The browser requests the server for the HTML.
- The server makes API requests and renders the critical content first, and sends it to the client.
- The browser parses the HTML and paints it on the screen.
- The server renders the non-critical content and streams it to the browser.
- The browser then parses and paints the non-critical content.
- 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.
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.
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.
Performance Analysis using Chrome DevTools
- 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.
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.
- 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.
By tracking down these kinds of performance issues, you can ensure that your web app provides your users’ best possible experience.
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 ?.
- Build Scalable React Apps by Sharing UIs and Hooks
- 3 Ways to Render Large Lists in Angular
- Improve Page Rendering Speed Using Only CSS
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.