Ask HN: Is it just me or is the AMP project making everything slower?

[gtf21]

I have µMatrix in my browser, and by default it blocks the AMP CDN. The result of this seems to be horrendous white-screen times for web-pages, beyond what I would expect it to take for a web-server to load these pages, and the delay in loading is very noticeable across all of them.

I have a vague idea of the point of AMP, which is to speed up the delivery of web pages. However:

1) I'm not convinced the web pages were really _that_ slow to start with, so it feels like an unnecessary project (well, excepting the fact that web-page bloat has massively increased as people use more and more javascript libraries &c.).

2) Perhaps I'm being a bit old fashioned, but I don't really understand what was wrong with a browser serving a web page made out of some HTML, CSS, and Javascript. It feels like we're replacing one technology with another (and that latter one comes from Google, which makes me nervous). Do we really want AMP to be the way we serve the web?

3) I haven't properly investigated, bt I'm assuming that this delay is some script which is waiting for the data to load from the AMP CDN, and once that times out it displays the underlying content (I did check and loading this page [1] is almost instantaneous yet the content only displays after three seconds). Any insight into why it's seen as acceptable for this to be so slow when it is unnecessary for displaying the page?

[1]: https://www.ehow.co.uk/how_5840711_test-electrical-outlet-digital-multimeter.html

[kjullien]

I 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 is that this animation is usually triggered before the 8s, as soon as the AMP javascript has been served from the CDN. Your adblocker of something of the sort is blocking it which results in you having to wait for the hard coded 8s fallback to see the page no matter if the content is already loaded.

AMP is beautiful.

[justinph]

I, too, sadly have to code on AMP bullshit for work.

To be a valid AMP page (at least, according to the Google overlords) you _must_ use the CDN'd AMP scripts. This is the very antithesis of what the world wide web is supposed to be about. IMHO, it's not at all unreasonable to block stuff from domains you don't trust, especially domains controlled by large surveillance corporations. The web should be more resilient. AMP makes it brittle.

[EvilTerran]

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 doesn't let you apply :style() rules to all pages indiscriminately, you have to specify a domain name pattern - which is pretty annoying, because the principle is evidently sound; this does work on the link in OP:

    ehow.co.uk##html[amp] body,html[\26A1] body:style(animation:none!important)

Hrmph.

Alternatively, you could use a CSS injection addon (or userContent.css, in Firefox) to add the rule to all pages:

    html[amp] body, html[\26A1] body {
        animation: none !important;
    }

Or do it with a userscript (ie via Greasemonkey or similar).

[edit 2]

It appears uBO is aware of a need for something like this - they provide an injectable "scriptlet" that adds the necessary CSS: https://github.com/gorhill/uBlock/wiki/Resources-Library#amp...

Unfortunately, scriptlet injection also can't be applied to every page indiscriminately. :/

    ! works on OP's link
    ehow.co.uk##script:inject(ampproject.org/v0.js)
    ! doesn't work at all
    ##script:inject(ampproject.org/v0.js)

So I'm just mentioning it here for completeness' sake.

[NeedMoreTea]

Thanks for the enlightenment, this explains why I no longer visit The Independent's website.

I naively assumed, to begin with, that they'd pushed out something broken. Except it never got resolved, which surprised considering the length of delay. So I resolved it by pretending they no longer exist.

I'll likely never know if they ever do resolve it.

[SimeVidas]

8 seconds? I thought it was 3.

That being said, this is most likely the culprit. If OP is blocking AMP CDN, the inlined CSS code will hide the content until the CSS animation completes after whatever the timeout is nowadays.

[lucb1e]

> code required for any AMP page to be valid includes: [sleep 8 to avoid rendering artifacts]

That sounds awfully convenient for whoever cooked this up.

[black-tea]

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.

[Falkon1313]

>I'm not convinced the web pages were really _that_ slow to start with, so it feels like an unnecessary project (well, excepting the fact that web-page bloat has massively increased as people use more and more javascript libraries &c.).

Right. It's super easy to make lightning fast web pages. In fact, that's the default state of a static HTML page. It actually takes a lot _more_ work to make pages slow by adding tons of javascript, dependencies, server-side applications, etc.

From the article linked elsewhere in this thread: >The 90th percentile weight for the canonical version is 5,229kb. [...] The 90th percentile request count for the canonical version is 647

There's the problem. Over 5 megabytes and 647 requests for one article? 5MB is equivalent to about 20 full-length novels or 1,000 pages of text. And 647 requests?! That must be one extremely comprehensive article, right? No, it's 1 request for a brief article and 646 unnecessary requests wasting bandwidth to load unnecessary stuff. Then people wonder why it's slow. But someone put in a lot of work to fluff that page up to be that huge and slow and use that many requests.

[pornel]

Yes, AMP is rather slow: https://timkadlec.com/remembers/2018-03-19-how-fast-is-amp-r...

and looks fast mainly because Google preloads it: https://ferdychristant.com/amp-the-missing-controversy-3b424...

[HALtheWise]

Sure, but from an end-user perspective, preloading is a perfectly valid way to achieve good performance, so it shouldn't be left out of the conversation. The fact that AMP can be preloaded without leaking your sensitive information to the owners of domains that you have not yet navigated to is a primary component of the design, and often gets ignored by armchair analysts.

[SimeVidas]

My takeaways from that article:

When comparing AMP pages to their associated canonical pages, the most striking difference is that AMP pages are significantly lighter (905 KB vs. 2,762 KB) and load significantly fewer assets (61 vs. 318 requests). (All numbers are median values from testing 50 pages.)

Many people have slow phones and expensive internet, and for them this difference enables them to browse news sites, literally.

[aboutruby]

The most frustrating is that AMP version of app/pages/websites are very incomplete, e.g. the AMP version of a reddit post has only 3 comments (and the "load more comments" button is buggy).

Would have been much better to use Lighthouse / PageSpeed as a basis for showing optimized pages.

[napsterbr]

Ugh, Reddit. Their amp version is terrible for the exact reason you mention. I know every time I see a Reddit page on Google results that I'll make two page loads instead of one (this does make a difference on my country, where everything is slow). Then, when accessing their pages on mobile browser, there's a huge banner telling me to download their app. In this same banner there is a dark UX pattern, where the call to action, giant button is to download the app, and the tiny footer text is "continue to mobile site". And apparently it doesn't matter I clicked through the banner before, it always displays the same annoying banner.

Sorry for the rant. I'm just genuinely disappointed in what the web has become.

[pkamb]

The multiple "Open in the Reddit App" banners that load for every AMP result, and do not remember that you've closed them in the past. Awful.

[shash7]

Not only that but tapping the top bar on iOS devices doesn't scroll the page to the top.

[jayd16]

Is bringing up reddit fair? The their new design is awful and only getting worse, AMP or not.

[justAnotherNET]

AMP is an anti-open-web disaster, and just another example of Google abusing their dominant position.

[gregable]

The open question is would it be better or worse without AMP? It's likely that reddit (for example) would have just deployed an equally frustrating "mobile" page that loads even slower.

I just tried fetching http://www.reddit.com/ in an incognito window (no personalization) on a fast connection and it took 1.2s to get the first byte on the connection. I can't say if this is typical, but the AMP Cache has much faster delivery (~30ms) even before considering the preloading.

[chuckgreenman]

I think there are definite drawbacks to the AMP project. For starters, it seems like the main goal is for Google to own more of the time people are interacting with the web, rather than anything else.

A mark in its favor though is local news sites. They are desperate to be at the top of the search page so when they join AMP, and you look at their AMP pages all of a sudden the loads of dark patterns they usually employ are absent.

[andy_ppp]

Maybe Google could just heavily discount for SEO popovers, slow sites, huge blobs of JS and generally stuff that we all find slow and irritating (i.e. jumpy images). It used to be the case that Google wanted to solve problems of their users but now Google wants to solve the problems of Google.

[acdha]

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.

[vivekd]

I'm trying to update my site to amp right now. I wrote the thing in django but it doesn't look like django is compatible with amp.

I'm switching over to php because it's the simplest language that seems to have CORS headers without requiring middleware packages. It seems like AMP can't even do something as simple as a contact form without CORS headers. I'm sure an experienced programmer could solve this problem easily but it makes things harder for amateurs like me.

It also doesn't seem to work with bootstrap so I've had to switch the whole thing over to basscss.

It seems like choosing AMP limits the other technology you can use.

[wmf]

Google isn't "owning more of the time"; all ad revenue, analytics, and branding accrues to the original site owner.

[dang]

I finally deployed code a few days ago to rewrite AMP urls on HN. It's tricky to get right. Fortunately Brian Eno was not playing.

https://news.ycombinator.com/item?id=18289349

[SquareWheel]

Shouldn't HN be grabbing the canonical URL from submissions anyway?

[ocdtrekkie]

This is fantastic. Thank you, dang.

[tgsovlerkhgsel]

> I have µMatrix in my browser, and by default it blocks the AMP CDN.

Maybe an unpopular opinion, but if you're getting a slow load/blank page because you're blocking parts of the content, yeah, "it's just you". Without the fallback mechanism that gets triggered after a few second, you'd just be stuck at the white page.

A good site will load faster than AMP, on a decent connection it may even be comparable to preloaded AMP. However, news sites have been pretty universally horrible at making good web sites. If someone stood behind their web developers and management with a whip, forcing them to build decent web sites and disallowing them from adding bloat, AMP would likely be unnecessary.

Part of the benefits of AMP is the possibility to preload, which allows for near-instant page opening from the search result page (unless you're blocking content, of course), the other part of the benefits is being that whip.

My overall experience with AMP has been positive.

[DyslexicAtheist]

> If someone stood behind their web developers and management with a whip, forcing them to build decent web sites and disallowing them from adding bloat, AMP would likely be unnecessary.

sadly it's the management, marketers, sales who are standing behind them and holding the whip. Most places measure engineering quality by how many features you can push through your CI/CD pipe (minus the fault-reports, breakage that the pipeline generates).

When everything works perfectly it isn't appreciated as it indicates that engineering isn't running at full capacity. The same problem we have with security and all resilience topics: how do you measure & budget (or in security monetize) something that is supposed to be invisible to the end-user?

As for AMP it's not just a tire-fire it's a clear attempt to break the open web and create lock-in for competitors.

[throwawaysea]

They're likely unrelated issues, but I am not surprised that those outside Google's happy path experience severe performance issues. Gmail has been horrendously slow ever since they launched their terrible redesign, with initial page load taking 10+ seconds and actions like opening up emails taking several seconds. I can't help but think this is because I don't use Chrome.

[jonas21]

So... you're blocking the AMP javascript from loading and then complaining that AMP is slow for you.

Have you tried not blocking the script?

[_fbpt]

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).

[SquareWheel]

Correct. You've broken the page by blocking only some of the assets. AMP loads fine if you allow all scripts or disable Javascript completely.

[gtf21]

This is not really the point, the point is that the page loads anyway, without the AMP scripts so there's really no excuse for having an 8s delay. I don't want this google stuff on every web page I visit, and frankly it's unnecessary -- this article could easily have been written using static HTML / CSS and it would probably have been easier to develop (as well as access).

[abalone]

I wish Google would just heavily weight fast-loading, responsively-designed pages in pagerank and call it a day. There's no need for a weird problematic proprietary format.. It just smacks of a power grab to keep visitors on google.com.

[jefftk]

> There's no need for a weird problematic proprietary format.

The reason we need AMP now is that you can't otherwise preload a page in a privacy-preserving way.

Webpackaging will allow doing this without AMP though: https://github.com/WICG/webpackage/blob/master/explainer.md

(Disclosure: I work at Google on making ads be AMP.)

[davegauer]

A thousand times yes. If Google actually cared about end-user "experience", the health of the Web, and accessibility, they would do exactly as you've described.

[WalterSear]

It's a power grab.

[JesseWright]

AMP pages take forever to load for me with Firefox and uBlock Origin. When I open a news story from Google's recommendations, which always open to AMP pages, it pretty much always takes about 15 to 30 to show anything on screen. I instinctively edit the link manually nowto try to go to the non-AMP version, which typically loads the content in under 5 seconds.

[Marsymars]

If you're using Firefox, you can just use the Redirect AMP to HTML extension.

[lsadam0]

AMP has always and will always be a garbage idea. Stop implementing AMP.

[super-serial]

Over the last couple years Google has acted like a dictator on the web. No more autoplay... except if you're Youtube, or these 100 approved sites. If you use Chrome... oh now you're auto signed in. You opt out of location tracking - we'll still track you, we don't care.

Don't give Google more power.

Implementing your website in AMP is basically handing the keys of the web over to Google. They're going to make it more and more ridiculous to stay AMP-compliant and you're going to be shut out if you don't play their game. Eventually they'll enable/disable features of AMP-based sites arbitrarily... similar to how they determine autoplay policy on their "approved sites list." Do you think Google should be the all-powerful being that determines what features you can have on your website? That's the future you're opting into if you implement AMP.

[newnewpdro]

I don't know about slower, but it's certainly made the web more annoying to use with piecemeal javascript support - which obviously benefits advertisers like google, if it makes more of us cease interfering with tools like noscript and µMatrix.

[anuraj]

AMP is a project that benefits only a giant corporation. Please don't support it.

[zzo38computer]

The content of [1] displays immediately for me (and I do not have document scripts enabled). There are <amp-...> elements; I don't know what they are, and they do not do anything.

For webpages that do hide everything, I define my own CSS overrides which prevents the <html> and <body> element from ever being hidden, opacity less than 1, or similar. Further rules can be added to prevent <body> from being animated or having transitions.

What is wrong with just HTML, without CSS and JavaScript, or in some cases just plain text and not even HTML?

[k_bx]

AMP is about guarantees that you can't have with regular JS. You guarantee to not do any sync JS and document.write() stuff when you use AMP. Personally, I plan to use AMP to make a better indexation of my app which I do as a SPA, and which seems to be poorly indexed by Google. I'll make sitemap pointing to AMP pages with content, which has "see full view" link on it.

[markovbot]

Yeah, I actively avoid visiting AMP and sharing AMP sites for this reason whenever possible. They just take so fucking long to load.

[kevingadd]

In my experience AMP is considerably slower unless I happen to be browsing in Chrome. It's probably an accidental result of how they implemented AMP, that framework is tuned specifically for Chrome in the first place (odd CSS hacks to nudge Chrome's compositor into behaving a certain way, etc.)

[anticensor]

We need amp.wexe, fully DOM-based AMP implemented in WASM.

[trynewideas]

"accidental"?

[slig]

This is what's keeping the screen white before showing its content https://news.ycombinator.com/item?id=17746886