5 ms·
Users like pages that load quickly, which amp is not a requirement for. Amp is designed to tighten googles grip on the web, nothing more.
by stephenr 8y ago
Users like pages that load quickly, which amp is not a requirement for.
Amp is designed to tighten googles grip on the web, nothing more.
- eitally 8y agoNo it isn't. It's designed to make the user experience better on sites that frequently host Google ads (and also often contain a ton of bloat, 3rd party js, poorly constructed DOMs, awful CSS, etc). The only way Google could proactively "solve" this problem was by creating a "standard", and then also offering to absorb end user traffic for sites that adopted the standard. FWIW, AMP is an open standard not solely owned or contributed to by Google. https://amp.dev/ https://amp.dev/
- abc-xyz 8y agoWhy is that the only way? Seems like they could easily have achieved the same result by significantly penalizing sites based on load time and number of external requests.
- mthoms 8y agoThis question cuts right to the heart of the matter. I've yet to see a Google engineer, executive, or "fanboy" address this question adequately. This thread will be no exception. Queue the crickets.
- notatoad 8y agoA fast load time when a page is indexed does not guarantee a fast load time when it is served up to the actual viewer. Serving the page from cache is the only way to guarantee that the page will still be fast when the user wants to view it.
- themacguffinman 8y agoBecause users want relevant search results much more than fast websites. Google already factors in a website's performance in their rankings, but weighing it too much over content relevance will make search results worse.
- pdkl95 8y agoIf they actually cared that much about making the results "relevant", they wouldn't mix a bunch of irrelevant suggestions into the results page, each marked with "missing: <query_term>" pointing out exactly how they ignored part of the user's request.
- mtberatwork 8y agoBy that logic then, what's the point of AMP if Google is saying page load speeds aren't really that big of a factor? Why go through through the trouble of deriving a whole new subset of HTML?
- themacguffinman 8y agoI discuss this in another reply chain: https://news.ycombinator.com/item?id=19681408 https://news.ycombinator.com/item?id=19681408
- themacguffinman 8y agoBecause users want relevant search results much more than fast websites. Google already factors in a website's performance in their rankings, but weighing it too much over content relevance will make search results worse.
- stephenr 8y agoHow is that relevant?
- abc-xyz 8y agoWhat's the difference between influencing positions and visibility based on AMP support vs overall page performance? If visibility is influenced by AMP then Google benefits, users using Google services likely benefit, web developers suffer, users not using Google services to view the content continue to suffer (because companies will continue to maintain two versions of the website, a bloated version with 100 external tracking requests that will be shared on twitter/reddit/facebook/hn/etc, and an AMP version that will only appear on Googles services), and the internet as a whole suffer. Whereas if visibility is influenced by page speed+external requests then everyone would benefit.
- themacguffinman 8y agoSome differences: - AMP is a transparent and unambiguous standard that leaves no uncertainty as to whether you are somehow "performant enough" to qualify for the simple but limited visibility boost (referring to the news carousel) - AMP prevents important usability problems beyond performance, like page content jumping - AMP can enable advanced/extreme performance optimizations by default that are somewhat rare in practice (eg. only loading images above the fold) or isn't really possible to do safely/properly without a spec like AMP (eg. preloading content before the user clicks the link without unpredictably disrupting the website's servers) or sometimes avoided due to cost (eg. fast global caching with Google's impressive CDN). Important for users in the developing world. Addressing your other points: - Users who don't use Google services don't suffer. AMP is not Google-exclusive, all the major search engines (like Bing, Yahoo, Yandex) are stakeholders in the AMP standard and are free to support AMP. AFAIK there is nothing in the AMP standard that favors Google over other search engines or any other platform that might support AMP. - Not sure how web developers suffer more from AMP. I'd think web developers would suffer more from trying to wrangle their bloated website performance independently rather than use a standard toolkit that enforces best practices and enables difficult/expensive optimizations out of the box. - It's not clear to me how the internet as a whole will suffer, but I suspect this is just general hyperbole and not a specific point.
- cannedslime 8y agoSo the solution to the shitty state of google ads is to submits to google and implement their new shitty product?
- driverdan 8y ago> FWIW, AMP is an open standard not solely owned or contributed to by Google. > https://amp.dev/ https://amp.dev/ amp.dev is owned and controlled by Google. ampproject.org is owned and controlled by Google. The core AMP team are Google employees. How can you possibly say it's not owned by Google?
- eitally 8y agoI don't believe either of these statements is true: "ampproject.org is ... controlled by Google. The core AMP team are Google employees." https://blog.amp.dev/2018/09/18/governance/ https://blog.amp.dev/2018/09/18/governance/ The TSC is independent and, at this point, the committee code commits are almost 4x the volume of Googler commits.
- driverdan 8y ago1. Do a whois on those domains and you'll see they're owned by Google. 2. The privacy policy on amp.dev is Google's. 3. Both sites are hosted by Google. 4. The license in the amphtml repo says copyright Google. 5. The OWNERS.yaml file in the amphtml repo list 3 people, all of whom work for google. 6. Per the contributing code readme, contributing code requires signing this Google CLA: https://cla.developers.google.com/about/google-individual https://cla.developers.google.com/about/google-individual 7. Looking at the last few merged PRs nearly everyone involved is a Google employee. I realize this could be a coincidence but I'm not going to analyze the whole repo. 8. The TSC is 3/7 Google employees. Regardless, until Google issues a legally binding release of the project to an independent organization it is owned by Google. The TSC and AC could be removed at Google's whim.
- skilled 8y agoI partly agree with this. If you run a WordPress blog, then EasyEngine [1] and OpenLiteSpeed [2] can really boost your site performance. The performance will be greatly affected if you run some cancerous theme with endless JavaScript calls. But both of the mentioned "engines" have changed the way I see blogging with WordPress. Best of all, this is accessible to your average user as well. DigitalOcean can spin you up an OLS instance in a minute or so... [1]: https://easyengine.io/ https://easyengine.io/ [2]: https://openlitespeed.org/ https://openlitespeed.org/
- lern_too_spel 8y agoUsers like pages that load instantly, which AMP is a requirement for (via preloading).
- kuschku 8y agoAMP pages loaded through Google search with hot cache load slower than some of the websites I've developed when loaded with cold cache. It's absurdly slow, uses tons of unnecessary JS, and it is a privacy nightmare because now I can't just use server-side GDPR and ePrivacy guideline compliant analytics anymore, but either have to give up analytics entirely, or have to use privacy-obliterating Google Analytics. And if a user ever loads the page with JS disabled (which all my sites are designed to support), AMP breaks and just shows nothing at all for over 8 seconds.
- lern_too_spel 8y ago> AMP pages loaded through Google search with hot cache load slower than some of the websites I've developed when loaded with cold cache. On a mobile device in India? Nonsense. Your page load time is dominated by latency, which the AMP user doesn't see because it is preloaded from near caches. > uses tons of unnecessary JS, Which of the JS is unnecessary? The JS to load images allows AMP not to preload images below the fold, which is absolutely necessary for speed and for being friendly to data plans. > now I can't just use server-side GDPR and ePrivacy guideline compliant analytics anymore Explain. You still get first party tracking that gets fired when the user clicks to your page and can get user consent via data-consent-notification-id. > And if a user ever loads the page with JS disabled In that case, it's the SERP's fault for showing the AMP page instead of the non-AMP page. In the normal JavaScript-enabled scenario, the SERP would be stupid to show your non-AMP page.
- kuschku 8y ago> On a mobile device in India? Nonsense. Your page load time is dominated by latency, which the AMP user doesn't see because it is preloaded from near caches. My test device is a Huawei Ideos X3 on a 56kbit/s throttled 3G connection. The same effect also applies with a Pixel 1 on the same connection, or either of the devices on a modern 3.9G LTE connection. (Tested on O2 net in Germany, works reliably better than AMP even and especially while on a train — if you've ever tried using O2 on the intercity train between Hamburg and Münster you know that every third world country has better internet than, I've seen 8kbps with 13 seconds latency there) > Which of the JS is unnecessary? The JS to load images allows AMP not to preload images below the fold, which is absolutely necessary for speed and for being friendly to data plans. AMP uses megabytes of JS for that purpose, I do the same in under 1kiB (even including an intersection observer polyfill). And my CSS is much much smaller as well. Part of why I get a 100/100 in all pagespeed and lighthouse tests, including when simulating mobile connections, while AMP pages get only 60/100. > Explain. You still get first party tracking that gets fired when the user clicks to your page and can get user consent via data-consent-notification-id. I want JS-free analytics that do not require tracking or any consent (GDPR allows collecting some information without consent, same with the yet unreleased ePrivacy directive with which AMP is not compliant anyway).
- notatoad 8y agoas long as google is using their grip on the web to drag crappy websites kicking and screaming into having acceptable load times, i'm okay with it. yeah, there's a few sites out there that are faster than amp. but most of them are not, and before amp the trend was certainly not to make anything lighter or faster.
- mthoms 8y agoSo why not just penalize slower loading websites? Would that not have the same end result? I'm frankly shocked that people can't see this land grab for what it is.