6 ms·

Faster Web App Delivery with PRPL

64 points by jameslk 6y ago

rektide 6y ago
i love it, but right now this section: > How do you implement the PRPL pattern? looks like 'burn it all down & try something else'. de-monolithizing the app, disaggregating the process is some of the most ongoing & interesting work in computer science. there are, however, few current examples that push this effort very far.
fareesh 6y ago
From what I remember reading service worker versioning, caching and expiry felt like it was riddled with gotchas. Does anyone know of a good resource that covers most of these?
jph 6y ago
How to run well on a wide range of phones and networks is a big challenge. The PRPL approach of preloading wastes bandwidth, and is a hard pain point for people who pay by bandwidth. Yet the load-on-demand approach is perceptually slower. Svelte and Sapper get pretty close to what PRPL is describing, including much of the guidance of Next.js & Nuxt.js. What can help? Browser hinting is one approach. Browser settings that make it easy to accept/reject irrelevant content are another approach. Browser proxies with compression and filters are another. IMHO success looks like the user's agent/browser/phone/desktop saying "Please use this kind of quality of service profile for now, and send what's most relevant."
- csande17 6y ago
  The best compromise approach I've seen is the one taken by instant.page: start loading the content during the touch down event instead of waiting for the actual link click event to happen. This buys you 50-100ms, which is often enough to feel "instant" on the 5G iPhones that most modern webapps are designed for, without wasting bandwidth.
Waterluvian 6y ago
I want this stuff formalized and implemented at the browser level, not some Web dev pattern, so that the browser can give the user control on its usage. When I’m at home with fibre I am happy with the idea of going ape and downloading all the things I might touch. When I’m at the cottage, mobile, etc. I would be irritated if your website did all that. I’d even love a way to decide just how much of a JPEG to download (that kind that LODs itself as you wait).
- dylz 6y ago
  What's stopping every major site from going "oh, our randomly generated tracking and ads are critical path", while they serve multi-megabyte heavily obfuscated JS from random URLs to prevent being blocked. This already happens, unfortunately.
  - swiley 6y ago
    Anything worth reading can be read in elinks.
  - rozenmd 6y ago
    That would get picked up as an enormous increase in Speed Index & TTI, and their Google ranks would fall accordingly.
azangru 6y ago
> PRPL strives to optimize for: > ... > Simplicity of development and deployment How? The description sounds pretty complicated, with all the code splittings, service workers, lazy loadings and server pushes...
- eyelidlessness 6y ago
  Describing the generalization of a complex solution is the first step to generalizing the solution
csande17 6y ago
Whenever I read articles about elaborate ways to optimize the delivery of webapps, I am reminded of the following advice from https://idlewords.com/talks/website_obesity.htm#fixes https://idlewords.com/talks/website_obesity.htm#fixes: > I want to share with you my simple two-step secret to improving the performance of any website. > 1. Make sure that the most important elements of the page download and render first. > 2. Stop there. > You don't need all that other crap. Have courage in your minimalism.
- wtallis 6y ago
  And since a lot of web developers clearly need some clarification on this: step one means that the important content needs to be included in the initial response to the HTTP GET, and delivered as HTML. You're failing at step 1 if the first thing you serve up is JS to request the real content, or if the first thing you serve up is JS that operates on bundled data to transform it into something the browser can start rendering. If you're obsessively worried about "flash of unstyled content", then recall that the user will always see something after they click the link to your page. Giving them an unresponsive blank screen for an indefinite period of time may not be the best first impression to make.
  - steve_taylor 6y ago
    Native phone apps don’t render their initial screen server-side. Why should web apps? They’re pretty much the same as phone apps, just on a different runtime. I make a distinction between web apps and web sites. Web sites should be server-side rendered (at least the initial render) for obvious reasons.
    - no_wizard 6y ago
      Native apps deliver 80-100% of their application at most once, all things being equal. Web applications do not do this, even with aggressive caching and using service workers. I’d also argue that the web is far more accessible than native apps, in that it’s cross platform and independent of any one vendor, currently. So there are valid reasons for considering the page load price of websites/web apps. Also, know your target audience. I’m decidedly not okay with non application sites loading megabytes of JS just to function. However I’m okay with complex functionality provider by my very good and feature rich web based email client need a few MBs of JS to work on initial load, because the features justify the cost in that case It’s not all or nothing
jiangplus 6y ago
I think PWA pattern is bad for most website, they are not designed to run offline, just pretend to be available while actually not. ServiceWorker mess up app lifecycle and cache control. I just wish Chrome allow me to just disable all ServiceWorkers. This PRPL is even worse, just makes the stateless HTML page stateful, keeping more active connections, and is a lot more complicated. If you want a fast to load page, please keep it simple.
- marvindanig 6y ago
  Strongly disagree. You are either using the service worker api wrong or don’t understand how slow and spotty Internet connections can be for a majority of users around the world. PWAs are a massive improvement of experience on the web—it lets you think of the end-user more than the developer experience.
  - CodesInChaos 6y ago
    It looks like one of those technologies that are useful in theory, but difficult enough to implement correctly that 90% of implementations will be worse than not using it (endless scroll being a notorious offender).
- deleted 6y ago
  [deleted]
digitaltrees 6y ago
How is this not a reinvention of restful page loaded websites? I understand that it doesn’t require reloading pages on requests but I don’t see that as a fundamental difference.
c-cube 6y ago
They cite Twitter as using this pattern. That's hilarious, considering Twitter is currently one of the shittiest site around : half the time I click on a Twitter link (I don't have an account) it leads to "you are not allowed to see this". After one or more reloads (actuary number seems to be rolled off a dice) I get to see the content, ie. 280 characters and maybe an image. I imagine they never tried to use their own website.
- tobr 6y ago
  I also get that infuriating message all the time recently. I seem to recall reading that it is some kind of heavy-handed security feature, but I can’t find any references for it... can anyone fill in?
  - twittair_pr 6y ago
    This issue is not being fixed because it improves the downloads of the native Twitter app, which makes more money (no ad blockers, push notifications, more tracking).
- sergeykish 6y ago
  Twitter is not accessible without javascript. It serves 15kB page and does not include these 280 characters. Even its CSP header (2kB) is much bigger than actual message. Instead it wants (hard refresh, uBlock) 49 requests 795 kB transferred 3.6 MB resources Finish: 7.60 s DOMContentLoaded: 1.03 s
  - colesantiago 6y ago
    > Twitter is not accessible without javascript. What did you expect, isn't the web now built this way, I doubt you can play a video from Netflix without javascript.
    - sergeykish 6y ago
      Glad to surprise you — most of the web works fine with first party CSS and images only, uMatrix: * * * block * * frame block * 1st-party css allow * 1st-party frame allow * 1st-party image allow Some use CDN, allow 3rd party CSS and images, that's almost uMatrix defaults: * * * block * * css allow * * frame block * * image allow * 1st-party frame allow Even facebook serves some visible content [1]. Yes, some sites require JS, youtube could have <video><source>, image lazy loading required JS, we've got <img loading=lazy> now. [1] https://www.facebook.com/lasytoy/ https://www.facebook.com/lasytoy/
SPBS 6y ago
All this complexity that would have never been needed if Twitter just kept their glorified blog post aggregator as a static website.
icemelt8 6y ago
Hot Take: This kind of extreme difficulty in making fast websites is pushing people to make native apps to upload on the app store. I am a web developer for as long as I remember, but I am seriously thinking of moving to native apps, who do all this bullshit for me and makes amazing good experiences possible without having a Rocket Science degree in PRPL.
tekkk 6y ago
I have a gut feeling this would be a huge PITA to maintain and to fix all the weird bugs users would encounter. Sometimes even though you can do it, maybe the bigger thing is should you do it. Perhaps if you have the money and time and your users care, not just you and your PO.

64 points by jameslk 6y ago

i love it, but right now this section: > How do you implement the PRPL pattern? looks like 'burn it all down & try something else'. de-monolithizing the app, disaggregating the process is some of the most ongoing & interesting work in computer science. there are, however, few current examples that push this effort very far.

fareesh 6y ago

From what I remember reading service worker versioning, caching and expiry felt like it was riddled with gotchas. Does anyone know of a good resource that covers most of these?

jph 6y ago

How to run well on a wide range of phones and networks is a big challenge. The PRPL approach of preloading wastes bandwidth, and is a hard pain point for people who pay by bandwidth. Yet the load-on-demand approach is perceptually slower. Svelte and Sapper get pretty close to what PRPL is describing, including much of the guidance of Next.js & Nuxt.js. What can help? Browser hinting is one approach. Browser settings that make it easy to accept/reject irrelevant content are another approach. Browser proxies with compression and filters are another. IMHO success looks like the user's agent/browser/phone/desktop saying "Please use this kind of quality of service profile for now, and send what's most relevant."

csande17 6y ago
The best compromise approach I've seen is the one taken by instant.page: start loading the content during the touch down event instead of waiting for the actual link click event to happen. This buys you 50-100ms, which is often enough to feel "instant" on the 5G iPhones that most modern webapps are designed for, without wasting bandwidth.

Waterluvian 6y ago

I want this stuff formalized and implemented at the browser level, not some Web dev pattern, so that the browser can give the user control on its usage. When I’m at home with fibre I am happy with the idea of going ape and downloading all the things I might touch. When I’m at the cottage, mobile, etc. I would be irritated if your website did all that. I’d even love a way to decide just how much of a JPEG to download (that kind that LODs itself as you wait).

dylz 6y ago
What's stopping every major site from going "oh, our randomly generated tracking and ads are critical path", while they serve multi-megabyte heavily obfuscated JS from random URLs to prevent being blocked. This already happens, unfortunately.
- swiley 6y ago
  Anything worth reading can be read in elinks.
- rozenmd 6y ago
  That would get picked up as an enormous increase in Speed Index & TTI, and their Google ranks would fall accordingly.

azangru 6y ago

> PRPL strives to optimize for: > ... > Simplicity of development and deployment How? The description sounds pretty complicated, with all the code splittings, service workers, lazy loadings and server pushes...

eyelidlessness 6y ago
Describing the generalization of a complex solution is the first step to generalizing the solution

csande17 6y ago

Whenever I read articles about elaborate ways to optimize the delivery of webapps, I am reminded of the following advice from https://idlewords.com/talks/website_obesity.htm#fixes https://idlewords.com/talks/website_obesity.htm#fixes: > I want to share with you my simple two-step secret to improving the performance of any website. > 1. Make sure that the most important elements of the page download and render first. > 2. Stop there. > You don't need all that other crap. Have courage in your minimalism.

wtallis 6y ago
And since a lot of web developers clearly need some clarification on this: step one means that the important content needs to be included in the initial response to the HTTP GET, and delivered as HTML. You're failing at step 1 if the first thing you serve up is JS to request the real content, or if the first thing you serve up is JS that operates on bundled data to transform it into something the browser can start rendering. If you're obsessively worried about "flash of unstyled content", then recall that the user will always see something after they click the link to your page. Giving them an unresponsive blank screen for an indefinite period of time may not be the best first impression to make.
- steve_taylor 6y ago
  Native phone apps don’t render their initial screen server-side. Why should web apps? They’re pretty much the same as phone apps, just on a different runtime. I make a distinction between web apps and web sites. Web sites should be server-side rendered (at least the initial render) for obvious reasons.
  - no_wizard 6y ago
    Native apps deliver 80-100% of their application at most once, all things being equal. Web applications do not do this, even with aggressive caching and using service workers. I’d also argue that the web is far more accessible than native apps, in that it’s cross platform and independent of any one vendor, currently. So there are valid reasons for considering the page load price of websites/web apps. Also, know your target audience. I’m decidedly not okay with non application sites loading megabytes of JS just to function. However I’m okay with complex functionality provider by my very good and feature rich web based email client need a few MBs of JS to work on initial load, because the features justify the cost in that case It’s not all or nothing

jiangplus 6y ago

I think PWA pattern is bad for most website, they are not designed to run offline, just pretend to be available while actually not. ServiceWorker mess up app lifecycle and cache control. I just wish Chrome allow me to just disable all ServiceWorkers. This PRPL is even worse, just makes the stateless HTML page stateful, keeping more active connections, and is a lot more complicated. If you want a fast to load page, please keep it simple.

marvindanig 6y ago
Strongly disagree. You are either using the service worker api wrong or don’t understand how slow and spotty Internet connections can be for a majority of users around the world. PWAs are a massive improvement of experience on the web—it lets you think of the end-user more than the developer experience.
- CodesInChaos 6y ago
  It looks like one of those technologies that are useful in theory, but difficult enough to implement correctly that 90% of implementations will be worse than not using it (endless scroll being a notorious offender).
deleted 6y ago
[deleted]

digitaltrees 6y ago

How is this not a reinvention of restful page loaded websites? I understand that it doesn’t require reloading pages on requests but I don’t see that as a fundamental difference.

c-cube 6y ago

They cite Twitter as using this pattern. That's hilarious, considering Twitter is currently one of the shittiest site around : half the time I click on a Twitter link (I don't have an account) it leads to "you are not allowed to see this". After one or more reloads (actuary number seems to be rolled off a dice) I get to see the content, ie. 280 characters and maybe an image. I imagine they never tried to use their own website.

tobr 6y ago
I also get that infuriating message all the time recently. I seem to recall reading that it is some kind of heavy-handed security feature, but I can’t find any references for it... can anyone fill in?
- twittair_pr 6y ago
  This issue is not being fixed because it improves the downloads of the native Twitter app, which makes more money (no ad blockers, push notifications, more tracking).
sergeykish 6y ago
Twitter is not accessible without javascript. It serves 15kB page and does not include these 280 characters. Even its CSP header (2kB) is much bigger than actual message. Instead it wants (hard refresh, uBlock) 49 requests 795 kB transferred 3.6 MB resources Finish: 7.60 s DOMContentLoaded: 1.03 s
- colesantiago 6y ago
  > Twitter is not accessible without javascript. What did you expect, isn't the web now built this way, I doubt you can play a video from Netflix without javascript.
  - sergeykish 6y ago
    Glad to surprise you — most of the web works fine with first party CSS and images only, uMatrix: * * * block * * frame block * 1st-party css allow * 1st-party frame allow * 1st-party image allow Some use CDN, allow 3rd party CSS and images, that's almost uMatrix defaults: * * * block * * css allow * * frame block * * image allow * 1st-party frame allow Even facebook serves some visible content [1]. Yes, some sites require JS, youtube could have <video><source>, image lazy loading required JS, we've got <img loading=lazy> now. [1] https://www.facebook.com/lasytoy/ https://www.facebook.com/lasytoy/

SPBS 6y ago

All this complexity that would have never been needed if Twitter just kept their glorified blog post aggregator as a static website.

icemelt8 6y ago

Hot Take: This kind of extreme difficulty in making fast websites is pushing people to make native apps to upload on the app store. I am a web developer for as long as I remember, but I am seriously thinking of moving to native apps, who do all this bullshit for me and makes amazing good experiences possible without having a Rocket Science degree in PRPL.

tekkk 6y ago

I have a gut feeling this would be a huge PITA to maintain and to fix all the weird bugs users would encounter. Sometimes even though you can do it, maybe the bigger thing is should you do it. Perhaps if you have the money and time and your users care, not just you and your PO.