6 ms·
It looks to me like the design for this was https://github.com/ampproject/amphtml/issues/3133 https://github.com/ampproject/amphtml/issues/3133 (Disclosure: I
by jefftk 6y ago
It looks to me like the design for this was https://github.com/ampproject/amphtml/issues/3133 https://github.com/ampproject/amphtml/issues/3133
(Disclosure: I work on ads at Google, and I'm friends with some of the people at the link. Speaking only for myself.)
- three_seagrass 6y agoSo tl;dr: Traditional HTML+JS ads have always needed an extra second delay to load because of cross-domain UX degredation, but because AMP is pre-caching pages, they're able to pre-cache the ads too? Is that what I'm reading?
- asdfasgasdgasdg 6y agoI believe that the idea is that if the ad is amp, you can be sure it will load fast and not impede the ux of the page, whereas if it's html/js, you can't. It isn't about whether it is cached or not.
- ngold 6y agoSo taking websites hostage and demanding a ransom in the form of an amp link. Thanks.
- asdfasgasdgasdg 6y agoIf the top-line goal is to make the page as responsive as possible, I'm a little stumped as to what the alternative would be beyond delaying the loading of arbitrary html and JS. Can you think of a way to load arbitrary HTML immediately and not cause any page responsiveness issues on, say, a three year old Android device?
- creato 6y agoBut this sounds like a technical limitation that makes sense? This entire comment chain is mostly people interpreting the lawsuit as claiming this was a deliberate artificial delay for business reasons and getting outraged about that, not a technical issue.
- ethbr0 6y agoIt's a little murky. If the status quo comes with a cost, because of practical uncertainty, and you provide an alternative that eliminates the uncertainty (and the cost), and then you use the elimination of the cost to prefer your own method... at minimum, that feels "not fair."
- Retric 6y agoWhy would it be unfair? A lot of UI delays come from uncertainty, it’s often a significant technical issue.
- nl 6y agoThere's further details about it here: https://github.com/ampproject/amphtml/issues/3133 https://github.com/ampproject/amphtml/issues/3133 And yeah, it's a technical issue.
- jeffbee 6y agoSo the suit in one paragraph claims that AMP isn't faster, then in the very next paragraph says that it is faster, but that's anti-competitive?
- kodah 6y agoThis is answered above. It is faster for arbitrary means, nothing substantive.
- ethanbond 6y agoWhere "arbitrary" can be swapped out for "malicious" and "anti-competitive."
- kortilla 6y agoIt’s not faster when the browser actually loads them. It is faster when google induces a delay to making it available to start loading.
- asdfasgasdgasdg 6y agoThe first article I found about this was https://timkadlec.com/remembers/2018-03-19-how-fast-is-amp-really/ https://timkadlec.com/remembers/2018-03-19-how-fast-is-amp-r..., which claims that AMP is actually faster in practice, probably mostly because it encourages good habits. Where are you seeing that it's not faster? This article is from '18 so perhaps there has been a change in how well AMP performs versus the baseline. Also worth noting that we should probably judge AMP as a whole product. What if it didn't make things faster at all, but did make them predictable and amenable to prerendering? The product is AMP+Cache+Prerendering. Prerendering unquestionably gives huge speed advantages in many scenarios. If you don't have AMP, you don't have prerendering, which means AMP-as-a-product gives significant speed advantages, since it's on the critical path to prerendering. (All of this is of course predicated on the idea that you can't practically prerender normal HTML pages, which perhaps you can, I don't know. I'm just saying if that justification for AMP is correct, it shouldn't necessarily matter that HTML+AMP markup is not faster than HTML markup.)
- morio 6y agoThanks for the link. Though as a Google employee you should probably refrain from any further public comments.
- dang 6y agoThere's nothing wrong with a Google employee participating in a Google-related discussion (edit: I mean in an HN thread of course), same as with any company. It's nice if they say so, which jefftk did. Edit: I misread. Corrected below. Sorry!
- NoodleIncident 6y agoI'm pretty sure they mean it's a bad idea from Google's perspective, not Hacker News'
- xyzzyz 6y agoNothing wrong with that, sure, but making comments related to ongoing antitrust litigation against company employing you, while not being any official spokesperson and not having your comments vetted by legal and PR, can be really, really detrimental to one's career if Google decides that it doesn't like your comments. Google is very explicit in its internal trainings to never make any public comments like that unless you're officially empowered to do so. You can say or write anything you want on HN... on the last day at your job.
- stainforth 6y agoIs Google legal going to extend their protection to you during this?
- abhinav22 6y agoFor the parents interest can we please delete his post...don’t want to see him get into any issues
- nprateem 6y agoHe can probably manage to do that himself if he wants.
- _cs2017_ 6y agoDo I understand correctly that the 1-second delay existed in both AMP and non-AMP case? And later, someone found a way to remove the 1-second delay for AMP since it could be done without a negative UI impact (unlike for the non-AMP case)?
- BrianOnHN 6y agoThat seems more likely than complete malice.