Malte Ubl
Yeah, it’s just really complicated for the page author to get right, and roughly ~zero docs that aren’t AMP on the web comply today. The proposed method works for all docs and is also almost certainly going to ship faster.
August 26th, 2019
Replying to
Yes, I linked to that in my post.
But this wouldn’t be “arbitrary” content—there would be strict criteria for admission.
It feels like there’s a big spectrum between “arbitrary” and “only AMP”.
Responses
Jeremy Keith
Oh, yes, I wasn’t suggesting that any pages are ready to be hosted and pre-rendered as they are today—there would certainly need to be some rejiggng done, either by the author or the host. adactio.com/notes/15730
Malte Ubl
Oh, and the proposed path fixes the URL issue. I really don’t want to go further down the pre-fix path. AMP is also switching to preloading for non-embedded experiences, so I really think aligning there makes sense.
Jeremy Keith
Is there a timeline on when we can expect to see non-AMP pages (with web packaging) getting the same preferential treatment as AMP pages in search? adactio.com/notes/15731
Malte Ubl
The next thing that is ready is preloading and “speed assessment via metrics”. No timeline, but within reach. Embedding cases like the image search swipe up are blocked on progress on portals.
Jeremy Keith
Is there a URL for where the discussion around “speed assessment via metrics” is happening? adactio.com/notes/15732
Malte Ubl
This has 2 parts: 1. the web platform metrics 2. Google’s proprietary system making the assessment (will be based on webmasters.googleblog.com/2018/01/using-…) The core new metrics are - LCP discourse.wicg.io/t/proposal-lar… - Layout Instability github.com/WICG/layout-in… - FID github.com/WICG/event-tim…