Design Review 2019-05-16 00:00 UTC (wg-amp4email, amp-prefetch-link)

[mrjoro]

Time: 2019-05-16 00:00 UTC (add to Google Calendar)
Location: Video conference via Google Meet

The AMP Project holds weekly engineering design reviews. We encourage everyone in the community to participate in these design reviews.

If you are interested in bringing your design to design review, read the design review documentation and add a link to your design doc by the Monday before your design review.

When attending a design review please read through the designs before the design review starts. This allows us to spend more time on discussion of the design.

We rotate our design review between times that work better for different parts of the world as described in our design review documentation, but you are welcome to attend any design review. If you cannot make any of the design reviews but have a design to discuss please let mrjoro@ know on Slack and we will find a time that works for you.

[mrjoro]

The AMP4Email Working Group will be presenting their periodic update at this Design Review (10-15 minutes).

/cc @choumx @ampproject/wg-amp4email

[cathyxz]

I'd like to present a design for solving the AMP List Resizing problem in context of the next version of amp-list aka amp-render.

[prateekbh]

i'd like to present a design for amp-prefetch-link.

[nainar]

We will be delaying discussion for the amp-list resizing issues till a later date.

[prateekbh]

^ design doc for amp-prefetch-link: https://docs.google.com/document/d/1Wxrc4G5vDyWfQEa56GflxEH2PGSs86Qz14ag0pLvBao?usp=sharing

[mrjoro]

amp-prefetch-link

• for new extension element, when would CSS rules need to change?
   - e.g. a rule where a hyperlink is a child of a parent, if we introduce a wrapper element they add
• @sparhami: does RequestIdleCallback only deal with JS busy-ness or network busy-ness?
    - mostly JS
    - @jridgewell; in that case, RequestIdleCallback probably doesn't make much sense; it doesn't cause any body style recalculation, etc.
• @jridgewell: to tie into resource prioritization we need to go with the custom element; resources has the idea of penalties (Ads at 2 seconds, everything else at 0; if we give this a high penalty and restrict the render distance outside of the viewport than resources will schedule this after everything else on the page has been scheduled--e.g. even if this is in viewport an image after the viewport would still get loaded first
    - @zhouyx: does the resource manager also account for network usage?  @jridgewell: no, nothing gives us network usage prioritization
    - @sparhami: browsers have some support for adjusting network usage for prefetching, e.g. on metered connections; networkinformation saveData (Chrome only)
• @zhouyx: we have link rewriter components, will they cause an issue?
    - @jridgewell: when does the rewriting happen?  @zhouyx: two versions, one at layout, one at click time; at layout time it would be an issue
    - @prateekbh will look into it
• @choumx: what prevents a publisher from sprinkling this everywhere at the cost of the user using a lot of data?  though they could do this today on regular pages as well
• @sparhami: do we allow the preloading today?  @jridgewell: we do, but we should make it inert  
• @sparhami: should we push people to use ServiceWorkers instead of this if it's same domain?  it's more than that
• @choumx: do we think the likelihood of the user clicking on a link changes as the user scrolls the page?  @prateekbh: we don't have a great way of knowing that
• @sparhami: should we wait until the user stops scrolling before we do this?
    - @prateekbh: is it the same case as amp-img where you scroll quickly past a bunch?  @jridgewell: currently, we're going to try to load all of them
    - @prateekbh: perhaps the runtime should handle this optimization?
• @choumx: should we just use the static link rel prefetch instead of this?  do we gain much extra by making it an extension?  could we add some logic into the runtime?  one of AMP's principles is solving things at the right layer (maybe even the browser)
    - @prateekbh: one downside of putting it in the runtime is that it's increases the size of the code for everyone, not just people using it
    - @sparhami: can we do something where we have a "core runtime" and a "delayed runtime" where we can put things like this

[mrjoro]

wg-amp4email update