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.
Ask HN: Is it just me or is the AMP project making everything slower?
61–70 of 189 posts
Re: Ask HN: Is it just me or is the AMP project making everything slower?
#62Earlier quoted context omitted.
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…
reddit user: > 2) Can you stop the "Download the app" popups showing up so frequently on mobile? spez (Steve Huffman): > 2) They've been gone a while, but we are chasing down an issue with incognito users seeing it more often. Please let me know if that's the case, or if you are having a different experience.* Also talking about dark patterns: https://old.reddit.com/r/announcements/comments/9ld746/you_h...
Imgur is full of coercive patterns too. On mobile it has a permenant "get app" button hovering over the content and you can't see user profiles or other social interaction stuff. It says you need to install the app to use them, even though they work fine on the desktop website.
Re: Ask HN: Is it just me or is the AMP project making everything slower?
#63Earlier 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.
I'm not sure if that's true. Even now they claim that page speed is only a small factor in overall page rank, and even _that_ applies to "only the slowest sites." https://webmasters.googleblog.com/2018/01/using-page-speed-i...
Re: Ask HN: Is it just me or is the AMP project making everything slower?
#64>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.
Re: Ask HN: Is it just me or is the AMP project making everything slower?
#65It's outright blocking pages for me, until the pages retry without AMP
Re: Ask HN: Is it just me or is the AMP project making everything slower?
#66Yes, 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...
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.
I too love single points of failure, and look forward to this Google-Internet.
Re: Ask HN: Is it just me or is the AMP project making everything slower?
#67Yes, 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...
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.
Can it be preloaded without Google having any pertinent information logged?
Re: Ask HN: Is it just me or is the AMP project making everything slower?
#68AMP 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.
If you're using Firefox, you can just use the Redirect AMP to HTML extension.
Re: Ask HN: Is it just me or is the AMP project making everything slower?
#69Earlier quoted context omitted.
Completely different. This is like a car that tries to phone home every time you start it, so either you keep the phone service active and get a salesperson talking to you while driving, or you disable the phone and the car leave the immobiliser active for a minute each time you try to start the car.
Are you upset that the website is using a CDN? That is the standard distribution method for common libraries. As for the other half of your analogy - stop poking holes in the gas tank and it won't need active service.
Using a CDN isn't the problem on it's own; the problem is the (unfortunately common) shoddy programming practice of assuming error never happen. Good programming almost always involves checking for and properly handling errors. Using the returned value from fopen(3) without checking if it was NULL probably results in the program crashing when displaying a simple "file not found" error message would have been more appropriate.
This principle is also true when writing web pages; if you load an external resource, you need to check for and handle the case where that resource might not be available. Failing to load a resource can happen for many different reasons, not just someone blocking it with their client. Proper handling the error depends on what the resource is: display the content that is already available (perhaps in a less than ideal state), or if that isn't possible displaying an appropriate error message. This includes cases where the Javascript itself isn't available (for any reason).
Networks are not reliable or universally available. Quality programming understand that and does the best it can when failures happen.
Re: Ask HN: Is it just me or is the AMP project making everything slower?
#70I 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 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.
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 "hide the screen until layout is done" trick to avoid multiple relayouts as the initial javascript is running and CSS is being fetched. More often than ideal, they don't have a fallback if the javascript doesn't load at all. AMP mandates it with this CSS animation, which is far better than nothing.
Also when served from the AMP Cache (https://www-ehow-co-uk.cdn.ampproject.org/c/s/www.ehow.co.uk... for the example shown), the layout algorithm that javascript runs is applied by the AMP Cache instead and the 8-second timeout code is removed completely (view source and take a look). This doesn't work on all pages - there are some features that require a client-side context, but it does work on this one. Websites can run the same server-side layout algorithm on their origin using a node library (https://www.npmjs.com/package/amp-toolbox-optimizer). There is also work being done to improve all of this (server side layout on more documents, and making the system easier to run on your own site).
The 3s observation from the original post is interesting. It may just have been an estimation of the 8s, or it could have something to do with how the document is configured. Looking at this document, there are some tags that the document author has added with a 3000ms timeout. These are tags that instruct the AMP javascript to change the document CSS class depending on the success of failure of loading of a particular font. By default (not amp specific), if a document loads a webfont for a particular text, the browser will not display the text until the font is loaded. provides a CSS hook by which the author can do stuff like "hide the text for up to 3s, or when the font has loaded, whichever comes first". This page has some tags with a 3s timeout referencing fonts that have not been added to the document, which seems like a mistake from the document author, unsure. I was not able to reproduce the 3s experience though, so this may be incorrect speculation as to what happened.