What is Distributed Persistent Rendering?

Distributed Persistent Rendering (DPR) is a new approach that aims to solve long deployment times. Those are usually caused by rebuilding thousand of pages each time you do even a little change on your static website.

Netlify introduced the DPR concept in April this year on Github as RFC (Request for Comments). By doing this in public on the jamstack.org repository Netlify suggests this should be a part of Jamstack’s future.

How does DPR work?

One of the Jamstack core principles is Atomic Deploys. Each time a new deployment completes it is pushed on a global Edge instantly revalidating all stale files. This guarantees the global consistency of every page for every user. This also enables developers to easily rollback to any previous build which can be a life-saver in situations when you accidentally break something on Friday evening.

Solutions like Incremental Static Regenerating, which is heavily based on the concept of stale-while-revalidate, don’t offer this.

The main use cases for DPR:

• archived pages with low traffic volume
• user-generated content which has a standalone URL after publication
• serverless function for image transformation and optimizations on the CDN

All those pages will be generated on the first user request. That means every first user is unlucky enough to have a longer response since Netlify needs to build the page first, cache it on the CDN and then serve.

All critical pages should be still generated during the build to achieve maximum performance for every user.

DPR Adoption

Unfortunately, none of the static site generators available at the moment support DPR in production. To make it work, SSG maintainers need to add support for a serverless function that builds a single page. The closest right now is Next.js, with its ISR concept that could be transformed to DPR quite easily.

Gatsby

Given the fact Gatsby maintains its own Gatsby Cloud which is optimized and designed to offer the fastest builds and almost instant incremental builds, I don’t think DPR will be a priority anytime soon. Gatsby doesn’t plan to add a serverless function to build a single page.

Eleventy

Zach Leatherman is working on DPR support for Eleventy. The new concept of Eleventy Serverless aims to enable DPR for Eleventy.

Unfortunately, no other SSG maintainers plan to enable DPR support soon which may be the biggest issue with a wilder adoption of the new Netlify (or Jamstack?) feature.

Non-js and non-go tools.

Netlify supports two runtime languages, JavaScript and Go. It makes it quite hard to support DPR for tools like Jekyll and Bridgetown since both are built on Ruby and would require it to generate pages dynamically.

Future of DPR

Jamstack is used by a lot of people and companies in marketing to better position products and services that fit into this ecosystem. Together we push the web and the Jamstack further. But Netlify is the main stakeholder, caretaker of the Jamstack future and they have the loudest voice.

It’s good for Jamstack that Netlify understands the current limitations and problems and offers a solution. DPR is an interesting approach, but the devil is in the details. And in this case in implementation.

Most likely Netlify won’t open-source any technical details on how Netlify implements DPR under the hood. The question is - will others Jamstack deployments companies adopt this as well?