Optimizing Assessments with Deferred Rendering

To enhance the speed and efficiency of your assessments, we provide the option to defer rendering, allowing you to optimize the rendering process by postponing the rendering of widgets (Question and Features) until they are actually visible. This article will guide you through the steps to enable deferred rendering using the defer_render initialization option and also explain how to listen to the rendered event to monitor this process.


What is Deferred Rendering?

Deferred rendering is a feature that allows you to delay the rendering of Items until they are actually needed. By enabling deferred rendering, supported widgets will only render at runtime if they are actually going to be visible. You can significantly reduce the initial rendering time of your assessments, especially when dealing with large assessments containing a large number of Items.


How to Implement Defer Rendering in Your Assessments?

To enable deferred rendering in your assessments, you need to set the defer_render flag in the initialization options. Here’s an example of how you can do this:


    "config": {
        "questions_api_init_options": {
            "render_optimization": {
                "defer_render": true

Code example 1: setting the defer_render init option


When the defer_render flag is enabled, widgets will only be rendered once their container becomes visible; in contrast to the default behavior where all widgets render at runtime regardless of their visibility. You can also check the render state of widget by using the isRendered() method, and you can monitor when widgets are rendered by listening to the rendered event.


Note Unsupported widgets will always render as normal at runtime, regardless of whether their container is visible or not. For a comprehensive list of supported widgets, please refer to the documentation.


How to Listen to the Rendered Event

The rendered event is triggered when supported widgets have finished rendering. Here's how you can set up an event listener:

itemsApp.question('[my_response_id]').on('rendered', function () {
    console.log('This code executes when the Question is rendered.');

Code example 2: setting up an event listener


What are the differences between Deferred Rendering and Lazyloading?

Both deferred rendering and lazyload are options that allow you to optimize the initial rendering time of assessments that have a large number of widgets that need to be rendered, but there are some differences to be aware of:


Table 1: deferred rendering versus lazy loading

Deferred Rendering Lazyload
Delays the rendering of widgets until they are visible. Renders all the available widgets in the background regardless of their visibility.
All items and widgets are available at runtime, but they aren’t all rendered at once - reducing the impact on browser performance. Items and their widgets have to be fetched from the Item Bank across several requests.
An additional staggered rendering option is available to render hidden widgets in the background at a configurable interval until completion. This means all widgets can still be pre-rendered in the background in a way that does not hold up the browser by rendering them all at once. Renders all the available widgets in the background at once as they are fetched from the Item Bank.
Supported widgets will defer rendering. Others will render in the background at runtime. All widgets will render in the background at runtime.
Was this article helpful?

Did you arrive here by accident? If so, learn more about Learnosity.