Check out a free preview of the full Progressive Web Applications and Offline course:
The "PRPL Pattern" Lesson is part of the full, Progressive Web Applications and Offline course featured in this preview video. Here's what you'd learn in this lesson:

Mike introduces the Push Render Pre-Cache Lazy-load (PRPL) pattern for PWAs. In this pattern, a developer would Push critical resources for the initial URL route, Render initial route, Pre-cache remaining routes, and Lazy-load and then create remaining routes on demand.

Get Unlimited Access Now

Transcript from the "PRPL Pattern" Lesson

>> Mike North: The second pattern that I wanna talk about, and this isn't a choice between App Shell and this other pattern. But it works well in terms of figuring out how we set up our different resources. This is called PRPL and again coined by Google Developer Advocate, think this was Addy that coined this one.

[00:00:23] And it's just an acronym that represents four steps here, the first is to push the critical resources for that URL to the browser. And this is where code splitting, route splitting, and HTTP push is really important. We have critical CSS, critical JavaScript for that URL. let's get that over the wire as quickly as we can in parallel and have that page render as soon as possible.

[00:00:49] And at that point we can render that initial route. So then we can, in the background, pre-cache any remaining route. So this is where you would go and in the background download additional fragments of your application so they're available instantly. That would be kind of the like the pre-caching that we've already been doing.

[00:01:07] Where we used that asset manifest. And then finally we'll lazy-load the remaining routes when they're ready. And you wanna defer actually evaluating the script because there is some cost for taking text JavaScript files. And turning them into executable code. There's no need to pay that cost until you're ready to actually use them.

[00:01:29] And so you can kinda keep them in the cache, from the cache API and they're is sorta inert there, it's just text. And then as you need them, you can send a request for them in your service or send it back to the application. And at that point it becomes code, it's evaluated and you can use it.

[00:01:50] So these are the two goals of PRPL. We're trying to minimize the time-to-interactive by shrinking the code that we send to the browser for a given URL. It's shrinking the CSS so we're not sending all of Twitter Bootstrap along. And we also wanna maximize our caching efficiency by trying to ensure that we have the most critical stuff first.

[00:02:14] So that if the user visits a page and switches to another one. Like you have VIZ first and then you can worry about images in other less prioritized resources later.