Today, many websites are fully fledged JS applications that, moreover, integrate third-party libraries and services, or remotely stored content, into their business logic or page layout. If such websites are accessed under poor bandwidth conditions, fetching scripts and assets as well as remotely stored content may take some time, causing impatient visitors to leave the site prematurely. This is where prerendering comes in. It additionally lets crawlers not able to handle single page JavaScript apps see the structure and content of your site, which is a prerequisite for SEO to be effective.

Prerendering doesn’t solve the underlying performance problem but counters it by doing some of the time and bandwidth consuming work in advance, on the (cloud-based) server side.

With prerendering, static versions of all or specific pages are generated beforehand and delivered instead of their dynamic, fully JS-enabled versions. Afterwards, these static pages are given back their full functionality. This way, the visible parts of the pages (including all their content) are available to visitors much earlier compared to pages assembled by scripts running in a low performing client-side network environment.

That said, let’s take a look at how prerendering can be configured, e.g., for the JustRelate Portal App.

Not all content is suited for being prerendered. Binaries, e.g. images, as well as special-purpose content such as redirects or invisible data objects, should be exempted to not waste time on producing output that is never used.

Since all content objects are based on object classes, it seems natural to offer a mechanism for excluding objects by their object class. This is exactly what the PRERENDER_OBJ_CLASSES_BLACKLIST array in the “src/prerenderContent.ts” file is for. As a default, it includes a couple of names of standard object classes whose instances are to be ignored during prerendering:

On prerendering your website, the Web Builder automatically generates a sitemap for crawlers to see and properly index your content. The types of the objects to include can be specified analogously to the list of object classes above, however, the array, SITEMAP_OBJ_CLASSES_WHITELIST, is a whitelist. In the Portal App it is set to:

The Portal App outputs its status to the console. If prerendering a page causes an error, the page is skipped, and prerenderContent().catch() is called:

You may want to replace this reporting logic with a call to your favorite application error tracking and health monitoring service like Honeybadger.

The prerenderer fills in a template, “src/prerenderContent/generateHtml.ts” to generate the pages of your website. If you want to adjust the contents of this file (e.g. add a meta tag or call additional scripts), the non-prerendering version, “/index.html”, should be checked for consistency.

For testing (and debugging) the prerendering procedure, simply execute from within the root of your app directory:

The last of the above commands starts a web server on localhost:8080 for you to check the prerendered pages using the browser of your choice.

If you have been experimenting with your local Portal App installation, we recommend to remove odd ends, especially dysfunctional widgets, prior to prerendering as they cause the page concerned to be skipped and thus to be unavailable in the browser.