Earlier quoted context omitted.
this happens to me maybe 1 or 2% of the time
But how do you know which 1 or 2% of the time it's happening?
If you don't notice that the article is missing some paragraphs, then the article has had a bad editor.
Ask HN: Is it just me or is the AMP project making everything slower?
141–150 of 189 posts
Re: Ask HN: Is it just me or is the AMP project making everything slower?
#142Earlier quoted context omitted.
Accessibility.
That claim is pretty shallow. The content is there, it's just hidden through css. If anything, a screen reader has access to the content earlier than the unimpaired people.
Accessibility is about much more than screen readers. If a user experiences problems accessing your site, that’s an accessibility problem, no matter what physical attributes that person possesses.
Re: Ask HN: Is it just me or is the AMP project making everything slower?
#143So... you're blocking the AMP javascript from loading and then complaining that AMP is slow for you. Have you tried not blocking the script?
Downloading a website sans scripts takes strictly less time than downloading and executing scripts. A website that hides its content for 8 seconds because scripts are disabled is a defective website which deliberately stops users from looking static content (amp uses css animation).
If scripts are disabled AMP uses to skip the 8s timeout, and renders quickly. The OP is getting slow loads because they're (a) silently blocking the AMP JS and (b) not running the section.
(Disclosure: I work on AMP ads on non-AMP pages, which I like because it means the ads are declarative)
Re: Ask HN: Is it just me or is the AMP project making everything slower?
#144Earlier quoted context omitted.
I agree with you. However understand that AMP actually does have a failsafe here, and it's exactly what the OP is complaining about. After a timeout (to allow for shoddy network conditions as you described) it will load the content as best it can. All three cases are actually covered (full-script support, partial-script support, and noscript support). That's more resilient than most apps.
no script support that makes you wait eight seconds in a technology to make things ×faster× isn't really support, is it?
If you turn off all scripts AMP has a block that disables the 8s timeout. The OP is blocking only external scripts, which not surprisingly looks a lot like a very bad network connection.
(Disclosure: I work at Google on making ads be AMP)
Re: Ask HN: Is it just me or is the AMP project making everything slower?
#145Earlier quoted context omitted.
Google could get the same effect by more aggressively factoring page load time & size into page ranking. They don’t because that doesn’t give them control over the ad ecosystem.
They did that for years already, I believe. It didn't work.
They chose not to make it significant, however, so we have no way of saying that it wouldn’t have worked if it’d been a aggressive as AMP’s targets.
Re: Ask HN: Is it just me or is the AMP project making everything slower?
#146Earlier quoted context omitted.
The problem is that preloading is brittle. I see AMP pages lagging only a daily basis which is much rarer for sites which follow best practices — that 100KB of render-blocking JavaScript makes AMP incredibly brittle.
The web isn't what it was back in the 90s and early 2000s though. Back then, you wanted a website to last because there wasn't much on the web to begin with. Those of us who were online owned a reasonable amount of web bookmarks that led us to nice solid pages that were designed to load nice and fast over slower connections. Nowadays, the landscape is way different. There are just so many "normal folk" on the interne…
Having been a web developer in that era, performance was definitely a big concern. People were more willing to wait but there were still limits and you had the same tendencies for developers to work on fast systems and forget the experience on slow ones.
AMP is also a worse experience than that was because in the 90s you were usually waiting on images to render and progressive display was usually possible so you could start seeing that fuzzy JPEG fairly quickly and read the rest of an article, whereas AMP by design prevents anything from displaying until it’s loaded and executed correctly so you often have to reload the page to see anything at all when it fails.
This matters because most of where AMP was marketed to are competitive fields and that means it’s training users that they’ll get what they want faster and more reliably somewhere else.
Re: Ask HN: Is it just me or is the AMP project making everything slower?
#147I sadly have to code AMP for work. The reason you see a white page is that the boilerplate code required for any AMP page to be valid includes : webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both; With visibility set to hidden for every element on the page. This is used to minimize page rendering artifacts for the end user, which is one of AMP's main goals, content should be fixed. The problem however here…
From my reading of https://www.ampproject.org/docs/fundamentals/spec , it looks like you could override this behaviour in uBlock Origin with a style cosmetic filter. Something like... ##html[amp] body,html[\26A1] body:style(animation:none!important) (I can't test it in my current browser, unfortunately, but I think that's right.) [edit] Update: I got to a browser I could test it on. Unfortunately, it turns out uBO do…
And if uBlock needs to be modified to make your Amp-adjacent experience better, it's probably a bug uBlock's team should be notified about.
Re: Ask HN: Is it just me or is the AMP project making everything slower?
#148Earlier quoted context omitted.
This CSS animation is just the backup in case the javascript doesn't load at all, really. After 8 seconds, the page gives up trying to prevent the flash of unstyled content and just renders, regardless of how bad the styling is. It also includes a block that renders the page immediately if javascript is disabled. The 8s thing is for network issues. Graceful degradation. Lots of documents (amp or not) use the same "hi…
> The 8s thing is for network issues. Graceful degradation. A mandatory 8s lag for a careful users doesn't sound graceful to me :-/ For HNers who weren't creating web back in 2009: we used to have another term as well, "progressive enhancement" that meant more or less "after we got a baseline working on all supported browsers we can add nifty stuff that doesn't work in IE.
Graceful degradation is often handled by changing timing on expected results. Timing is often a useful unconstrained "fudge factor" for such things. And since disabling non-standardized intermediaries mucking about in your browser's w3c-compliant behavior is a solution, I doubt Amp will change to address this failure mode.
Re: Ask HN: Is it just me or is the AMP project making everything slower?
#149I sadly have to code AMP for work. The reason you see a white page is that the boilerplate code required for any AMP page to be valid includes : webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both; With visibility set to hidden for every element on the page. This is used to minimize page rendering artifacts for the end user, which is one of AMP's main goals, content should be fixed. The problem however here…
8 seconds! I remember browsing the Web in the early 2000s on a good connection and pages loaded fully in a matter of milliseconds. It was often imperceptible. Oh how we've regressed.
>I remember browsing the Web in the early 2000s on a good connection and pages loaded fully in a matter of milliseconds.
That has to be rose-tinted glasses. Networks used to be excruciatingly slow. I would walk away waiting for page loads during the dial-up era. Our expectations have simply been adjusted over time.
Re: Ask HN: Is it just me or is the AMP project making everything slower?
#150Earlier quoted context omitted.
They could have fixed this in a heartbeat by simply having pagerank penalize pages for adding external JS assets. No AMP needed; better experience all around, and with less effort.
That just leads to every page on the web hosting its own copy of jQuery. The whole purpose of external JS is to reduce load times by sharing cacheable libraries (admittedly with the side benefit of less bandwidth for the host). And if you think a whitelist would work, all it takes is one look at how rapidly new JS libraries come and go to render that unfeasible
You would use content names rather than location-based identifiers in that case.