Evaluating link-prefetch module vs Quicklink about amp-sw HOT 9 OPEN

So, to be clear... we're aligned on create an AMP Component for this usecase and remove the functionality from the ServiceWorker code?

Pick a +1 or -1 to indicate!

from amp-sw.

Biggest PRO in my head for an amp-component would be:
If we implement <amp-quicklink> as an AMP component then the resource-manager can just take care of when to prefetch the link and save the user from prefetching any extra data.

I believe an implementation of <amp-quicklink> or similar shouldn't target API compatibility with the standard version... instead should implement the intended functionality with the minimal configuration required for the AMP restricted space.

from amp-sw.

To start the conversation, let's list out the pros and cons for prefetching work in an AMP Component versus ServiceWorker. @prateekbh and @westonruter, please add in or correct me if I am misinterpreting.

ServiceWorker

• PRO Off main thread: reduces interference with main thread JavaScript execution.
• PRO Customizable caching behaviour via ServiceWorker cache.
• PRO Customizable request headers.
• CON Prefetching requires ServiceWorker integration.

AMP Component

• PRO Simple to add to existing documents.
• CON Additional configuration script in document.
• CON Additional main thread code execution.

from amp-sw.

Just a few things to put em out there before any further discussion:

• Currently for link prefetching we use a link prefetch when available to let the browser decide when its a good time to do the prefetching with lowest importance, we use service worker as a fallback for when link prefetch is not supported at all.

• Another thing to note is that we currently do need some work on main thread to at-least look at the DOM, check which links are to be pre-fetched and tell the service worker to prefetch them.

================
Now, quicklink definitely adds a bunch of stuff before just prefetching those links and depends on a bunch of APIs(Intersection observer and requestIdleCallback) whose presence are not guaranteed and would need to be included in order for Quicklinks to work perfectly.

On the other hand a component of <amp-quicklink>(whether it uses quicklink or just amp's inViewportLifeCycle method) will give a very clear intent for its work and will save the user from any unnecessary fetching of links which they will never visit because the link never came in the viewport.

from amp-sw.

Biggest PRO in my head for an amp-component would be:
If we implement <amp-quicklink> as an AMP component then the resource-manager can just take care of when to prefetch the link and save the user from prefetching any extra data.

from amp-sw.

we use service worker as a fallback for when link prefetch is not supported at all.

If we are only planning to use the ServiceWorker as a fallback, this gives additional coverage to Safari on iOS only right? Might be quite complicated to maintain for a single fallback.

Another thing to note is that we currently do need some work on main thread to at-least look at the DOM, check which links are to be pre-fetched and tell the service worker to prefetch them.

This limitation is disappointing, should we be writing a specification for inspecting document responses inside a Worker? My hunch is if we are planning to use the ServiceWorker to execute the work, it should be as much as possible off main thread (or the benefit is quite lessened).

from amp-sw.

Totally agreed!
Something as simple as <amp-quicklink href="......" /> should do the needful.
We can definitely use some inspiration from Quicklink but does not need to stick to its API layer or implementation.

from amp-sw.

I believe an implementation of <amp-quicklink> or similar shouldn't target API compatibility with the standard version... instead should implement the intended functionality with the minimal configuration required for the AMP restricted space.

Fwiw, I'm highly supportive of this direction. The alignment on implementing similar functionality (even if not directly requiring standard compat for quicklink's API) is also par for the course of how we've seen a few other OSS projects approach integrations.

from amp-sw.

Hi folks,

This issue and the other related one haven't been updated for a while now. Can we expect that <amp-quicklink> component to come up at some point during Q1?

We were thinking that some companies working on AMP-First sites (e.g. publishers), would be interested on trying this.

I'm currently helping maintain the quicklink library, so If there's anything we can do to help, please, let us know.

from amp-sw.