Like Jamstack, Netlify is coining this term.
If your reaction is: great, a new thing I need to know about and learn, know that while Distributed Persistent Rendering (DPR) does involve some new things, this is actually a push toward simplification and leverages ideas as old as the web is, just like Jamstack.
It’s probably helpful to hear it right from Matt Biilmann, CEO of Netlify:
In that short video, he makes the point that React started out very simple and solved a lot of clear problems with JavaScript architecture and, as time goes on and it tries to solve more use-cases, it’s getting a lot more complicated and risks losing the appeal it once had in its simplicity.
Jamstack, too, faces this problem. The original simplicity of it was extremely appealing, but as it grows to accommodate more use-cases, things get complicated.
One of those complications are sites with many-thousands of pages. Sites like that can have really slow build times. It’s nice to see frameworks tackle that (Google “Incremental Builds {Your Favorite Framework}”), but heck, if you change one link in a site footer, you’re re-building the whole site based on that one change.
So instead of building many-thousands of pages during a build, say you just… didn’t. Until that page is requested once, anyway. That’s
Here’s Zach Leatherman doing that. He finds a spot on his site that generates some 400 pages on each build and tells Eleventy that instead of building it during the normal build process, defer it to the cloud (literally a lambda will run and build the page when needed).
Deferring those 400 pages saves seven seconds in the build. Say your site is more dramatic, like 16,000 pages. Scratch pad math says you are saving four minutes there. It’s not just time either, although that’s a biggie. I think of all the electricity and long-term storage you save building this way.
Here’s the Netlify blog post:
Just like coining the term “Jamstack” didn’t mean inventing an entirely new architecture from scratch, naming this concept of “Distributed Persistent Rendering” doesn’t mean we’re creating a brand new solution.
The term “DPR” is new to us, but in a lot of ways, we’re taking inspiration from solutions that have worked in the past. We’re simply reworking them to fit with modern Jamstack best practices.
I like that it’s not like this entirely new thing. I’m sure Netlify’s implementation of it is no joke, but for us, it’s very easy to think about:
- Some pages are pre-built as usual
- Some pages are not built (deferred)
- When the non-built pages are requested for the first time, then they are built and cached so they don’t need to be built again.
That’s it, really.
It reminds me of how old WordPress caching plugins used to work. When a page was requested for the first time it would run the PHP and MySQL queries and all that, then save the result as an .html
file to the disk to serve subsequent requests. Not new, but still efficient.
The trick to a DPR architecture on Netlify is using their (beta) On-Demand Builders, so here’s the blog post that explains everything and will get you to the docs and such.
Sounds like they are moving towards old WordPress, just without a traditional database
If this technology existed in the past why is someone just changing the name and coins it ? Maybe I don’t understand this properly but if old WordPress cache plugins did the same thing, why is it news now?
Just because it’s similar conceptually doesn’t mean it’s literally exactly the same thing and unworthy of a name.
I guess the compromise is a slower experience for the first visitor to an unbuilt page. How much slower would be interesting.
Interesting skill for the developer to select which pages not to build too. Based on analytics, our preferred ‘route’ through site or just best guess.
We could ping pages automatically to trigger builds, just less frequently than typical build cycles. However, this loses the energy and storage gains and reintroduces more complexity.
Lots to consider but another step forward for the jamstack I think.
Right! My guess is it’s probably pretty fast. A static site generator running ONE page can’t be too bad. But you’re also paying for spin-up costs of the Lambda and the software, so it’s worth having details. To me it feels similar (conceptually) to the un-cached price we pay for any web asset that first time.
What’s funny about static site generators is that that used to be the norm way back in the late 90s I think, because servers back then used to be really slow and web technologies (server-side) were hard to use. Then came cafelog/Wordpress and everyone was blown away by not having to regenerate dozens or hundreds of pages every time you changed a footer link. The database was in charge of the actual data. With the fast and powerful servers of today, it amazes me how some people are creating sites the old way and even coining new terms like the main topic of this article when you can use a CMS and a caching system that provides the best of both worlds.
How is this different from NextJS “getStaticPaths” with revalidate flag?
I could easily have this wrong… but is that the “Stale While Revalidate” pattern? If so, I think the difference is that that pattern serves stale content at first and then updates with fresh content after a network request, while the DPR pattern serves fresh content on the first request (with the delay it takes to generate that fresh content on the very first request).
Seems like this has just come full circle to traditional Web architecture with full page caching
is this different than ISR tossed by Next.js?
Via Cassidy’s explainer:
What about SEO, especially since the search engine pushes to include its “Core Web Vitals” with LCP soon.
If this is true
I guess it wouldn’t be a big deal ;)