Faster Web App Delivery with PRPL | Hacker News Reader

Faster Web App Delivery with PRPL

addyosmani.com

64 pointsjameslk32 comments

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.

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

> 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.

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/

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?

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).

I had that error for years, but it evolved. Nowadays Firefox (desktop and mobile) just refuses to load anything due to a "protocol violation error" unless I hard-refresh with CTRL-F5.

I gave up trying to fix it.

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:

> 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.

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.

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.

> I make a distinction between web apps and web sites.

This is an important distinction to make. But far too many web sites try to place themselves in the "web app" category when they really don't belong. Using a heavyweight JS framework does not automatically make your blog or news site into an app; it just makes your blog or news site slow.

I've long thought that browsers should move to formalize the distinction between traditional web sites, and web apps. Apps should get access to the richer, more invasive APIs but only when the user instructs the browser to grant app-level permissions to the site, and at the expense of having stricter security and privacy policies enforced (ie. no third-party cookies, and probably no third-party scripts).

> Native phone apps don’t render their initial screen server-side. Why should web apps?

An extra RTT to local storage is pretty much always quicker than an extra RTT to a server. And it's not exactly unheard of for a mobile OS to cache a raster image of an app's screen to use the next time the user launches that app or browses through their collection of running apps.

I second that. Browser distinction between web apps and web pages is an awesome idea. I think the hard part is preventing users from learning to always click 'yes' to web-app level permissions just because the page instructs the browser to do so. I don't know the solution to this.

> I think the hard part is preventing users from learning to always click 'yes' to web-app level permissions just because the page instructs the browser to do so. I don't know the solution to this.

The key requirement is that putting a site into app mode must be a tradeoff, not a mere expansion of capabilities/permissions. There has to be a disincentive to discourage non-app sites from unnecessarily requesting app-mode permissions. The most natural way to accomplish this would be restrictions that make it less practical and more expensive to exploit broader permissions to abuse users. Eg. if you want the browser to prompt me to give your site access to my location data, your site should have to surrender the ability to load trackers and ads from somebody else's servers—you should have to serve that up yourself from your own domain, or not at all.

This would obviously break a lot about how things are commonly done on the current web, but most of what would be broken is the creepy stuff that we probably shouldn't be tolerating to begin with, like the monstrosity that reCAPTCHA has turned into under Google's stewardship.

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

I like idlewords' advice and I'd follow it for websites, but for web apps if there is a point where you can split the code then it is faster to load in stages. For example, in the app I work on when you first load the page it shows you a login form. While you're filling that in your browser is busy prefetching some assets (components, styles, icons) you'll need after you've logged in. It reduces the waiting time when you're using the app by a few seconds.

(To answer the obvious 'what a waste if the user fails to log in!' criticism, that's fewer than 0.2% of log in attempts. Most people benefit.)

Challenge is Chrome downloads images at a lower priority than scripts

Even bottom of body scripts (unless marked as defer) will download before images

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).

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.

That would get picked up as an enormous increase in Speed Index & TTI, and their Google ranks would fall accordingly.

Anything worth reading can be read in elinks.

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."

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.

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.

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.

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).

> 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...

Describing the generalization of a complex solution is the first step to generalizing the solution

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?

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.

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.

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

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.

Reply on news.ycombinator.com