A letter about Google AMP
ampletter.org
ampletter.org
This only helps the heavy handed SEO optimized sites with deep pockets and time to kill get yet another edge.
The article with the best insight isn't likely to be the one with the perfecly optimized website.
I understand that pagespeed effects end user experience when they hit a website, however that's not what I searched for. I did not search "fastest website with okay knowledge about dogs" I asked for "website with the best knowledge about dogs".
I want Google to be able to show me the most awesome page about dogs. The most in depth and relevant information. That niche dog blogger who is so passionate that they spend all their time researching dogs. I don't want "10 cool facts about dogs by Buzzfeed".
Let's say the page with the best information about dogs took an infinite amount of time to load (never loaded). I don't think you'd want that page to be ranked highly.
What about if that page took a year to load?
What about if that page took an hour?
A minute?
What's your cutoff? Let's say, generously, that you're willing to wait 30 minutes for the page to load. Why such a sharp cutoff? Why do pages that take 30 minutes and 1 second to load get penalized, but pages that take 30 minutes are treated as fine? The user experience is basically just as acceptable (by your standards) / just as bad (by my standards).
Perhaps maybe instead of a sharp cutoff we need some sort of sliding scale, where pages that are only slightly slower than optimal are penalized only slightly, and pages that are much slower than optimal are penalized more.
Gosh, that sounds familiar.
Also your example of a year is obtuse. It's like saying you should drive BMW because you will get killed in a Tesla if you crash at a million mph.
What Google's page speed factor does is differentiate between 1.5 and 2.5 seconds loading time. That has nothing to do with the quality of a page.
If it is truly the best information, it is what I want and I will wait. If I trust that Google can give me the best information then I would be willing to wait. I give up easily now because I can't trust Google to give me quality results. I will not wait for an ad bloated news aggregator.
The tricky thing is also the fact that Google does not inform the user that it is prioritising the faster loading pages instead of the pages with the most accurate match. This is a little dishonest too.
Pages that should be heavily penalized are those with lots of extraneous JS, bloated CSS files, lots of auto play videos, and huge image files that are supposedly created by “experts” that need a DevOps team to deploy and distribute all the bloat.
Sometimes images make sense.
Art collections are easy to develop with icons and progressive images.
Progressive images... eh. The js you load for it is 3-4x the images at 720p. Progressive jpeg, that's better.
The same IMO can be applied to speed as a factor. A slow site, (due to depth of content?) badly marked up but providing the correct result should outrank the fast site providing wrong info.
This sounds plausible, but doesn't translate to reality. Look at the slowest content sites today: they're large, well-resourced news sites. Look at the small, independent individuals running their own personal site: many are very fast.
In reality, I'd say the biggest causes of website performance issues are (a) institutional bureaucracy - managers requiring their website to do something without regard for the overhead and (b) professional graphic designers defining UI features without technical knowledge of their implemention details. These are both, usually, corporate inefficiencies that have little effect on smaller maintainers.
That is, by also having less bytes in the page, then less bandwidth is used. Since less bandwidth is used, less energy is used.
Unfortunately, Google doesn't measure, nor seem to care about energy consumption, as GoogleBot only cares about response times. (Of course, there are energy concerns regarding that too...but it's only every about speed with google and punishes everyone else for not evangelising it)
Using Page Size as metric has important benefits that Page Speed deliberately undermines. It also resurrects the notion that using external cached css and js is a good thing.
Did you know that in order to get 10 urls (the thing that you and I actually want) from google, you need to download 500K? It seems ludicrous to me. Each search result is chock-full of css and js that doesn't change.
Thankfully HN is old-school and uses external files and good-ol' minimalism.
2c
If you can test speed close to the requester geographically, it's possibly an even better indicator of energy usage because it also implies the data doesn't have to travel as far.
Also, Google has no idea what external resources your browser has cached locally.
I'm pretty sure they have enough data to figure that out.
That isn't what search is ranking. It's ranking what users want. And users very most definitely want, on average, among other things, fast.
As an aside, gaming on satellite internet was a real drag, the only game I had that would handle the full seconds of latency was Star Wars Galaxies. Thankfully that was already a favorite.
But who will measure it "objectively" (leaving aside no one agrees on how to universally measure load speed).
Googlebot? From what location and what machine types and how often? Should I get search results based on an average of all possible variables or the closest matching my locale and device? What happens when page content changes? What happens when the page sometimes loads slow content (e.g. ads) and sometimes doesn't? What happens when SEOers start cloaking their ad loads or taking advantage of flaws in the benchmark?
It's good to have a speed signal in search rankings, but this petition shouldn't pretend that's an objective replacement for something that always displays content first and loads media and third party content async
One potential solution that fits the theme of the letter could be logic like this:
MAX = <reasonably fast load time>
if page loads in > MAX:
-> punish page rank
if page uses GOOG proprietary:
-> show at the very top
-> trick anyone that clicks
-> profit
else:
-> ban website
-> reach out to sell AdWords
"Reasonably fast" could also be defined more loosely as "page uses good optimization practices" (e.g., like a YSlow grade).
> MAX = <reasonably fast load time>
Privacy reasons mean that it is basically impossible to load the content from the publisher's server until after the user clicks on the result. If you wait until the user click event to load the content, then there is nothing you can do to avoid a full network round trip.
AMP preloads the minimal content before the click, removing the round-trip. That's the whole magic, and the only way to get the 'instant' load.
There are unavoidable technical requirements to do this:
- Loading from Google's (or link provider X's) servers to preserve privacy.
- Constraining the html so that the load itself can't break privacy or add jank to the search result page.
If you aren't willing to accept these constraints, then you are always going to face a network round-trip in added latency. You can't have all 3 of:
- Zero perceived latency
- Privacy
- Serving from the publisher server
You can only pick 2. AMP forces choosing the first 2 which are what the vast majority of users care about.
Then AMP goes way out of it's way to give publishers back everything they could possibly miss from the 3rd.
Why this? If the HTML is already loaded from Google's servers, the load shouldn't be able to break privacy even more, and jank shouldn't be affected by the specific HTML that's being served, just by its size. So Google could just preload everything that's small enough.
If you do constrain what can run in your preload to avoid these, you end up designing AMP.
There is another way which enables almost instant loads. Turn off js completely. Try it yourself before you disregard it. It literally turns page loads instant over a regular home connection.
On some wired connections, a network round trip is within user-perceivable 'instant', but for many people on mobile devices, this is very noticeable.
https://hpbn.co/mobile-networks/
Even on the best LTE networks, the 'core network latency' is 40-50ms. 'core network latency' is the latency for getting the packet from the phone to tower to the packet gateway. This is before the packet even goes on the internet. And you need to double it for the round trip. You usually need to double the whole thing for initial DNS lookup.
Best possible latencies for an html page load on excellent LTE connections without prefetching are around 150-200ms. Most users in the world will experience >1s. A United States major city wired connection is not at all representative of what most people experience on a mobile connection.
Just look at Time to First Byte (TTFB); when you pile on SSL negotiation (since most have moved to HTTPS), the advantage is even greater since all AMP pages currently fall under the aegis of Google's domain and all non-AMP pages will require that overhead at first click.
They factor in all that stuff to a user happyness metric which impacts rankings, probably via a bunch of machine learned models.
The AMP logos and stuff are to try and force webmasters to take speed seriously. For years people have said it's important, yet big sites like eBay and Amazon, who certainly have the financial means and motivation to, still take 10x longer to load than what would maximize both revenue and user happyness.
And speed is way down on the list. Try searching for lyrics to any popular song and tell me it isn't so.
All they really need to do is add more weight to it. But they don't want to because that breaks the lock-in that they are striving for.
(Of course User permission must be granted, but shouldn’t that be feasible?)
This data is a much better indicator of how fast a page is vs if it is AMP or not.
https://webmasters.googleblog.com/2017/11/engaging-users-thr...
It is a horrible predictor of load times.
Seriously?
Not every city; the top 500 cities would probably cover 90+% of the users.
You're not understanding the scale of Google. They're incredibly good at exactly this stuff.
Is a cable is cut between Jakarta and Singapore, it can take months to fix as Indonesia only allows Indonesian-flagged cable layers to operate in its waters.
Individual datacenters, CDNs, cables are going offline constantly, so you'd need to be continuously testing every site to rank it correctly. Not only that, each page in a site might have a very different structure, so you can't just rank a site, you need to rank individual pages and articles too, which means testing every new page and article from every city.
I guess you're not getting the scale of that...
AMP standardizes the CDN serving part, largely eliminating that issue. AMP articles can't prevent 3rd party CDNs from caching them, which means that they can be served from the closest CDN after the first time they are used.
Which is the reason why Google focuses so much on the number of roundtrips. For most, downloading 50kbyte doesn't cause a lag but 10 roundtrips before the site can be rendered do.
An user in Indonesia isn't at the closest datacenter in Singapore. It doesn't matter what you do, you can't, from Singapore, try to emulate what an user on a particular ISP in a particular city in Indonesia will face.
In case it isn't clear:
Consider 2 websites, both have hosting in Singapore, but one also uses a CDN in Jakarta.
The Google crawler running on the Singapore datacenter connects to both websites, speeds are great because they are sitting just next to the datacenter. Both get great ratings.
An user is in Jakarta, and tries to connect to both websites. One of them takes a century to load, because it has to load everything from Singapore, and international cables from Singapore to Jakarta are expensive, so connections are capped. Experience sucks.
The second website uses a CDN in Jakarta, located at the local coloc facility to which the user's ISP is also connected to. The website loads instantly.
CDNs today are located in every single small ISP, in all countries, in all medium-sized cities in the world.
CDNs are a hack that can make websites load a bit faster, but that's about it. It won't make them use less RAM, or consume less of your data cap. Ultimately, performance is about the size of the site, the resources it uses on the client, and the number of requests it makes. All of which is independent of the number and location of CDNs.
If you pretend that all your users have net connections like the US, Europe, or parts of east Asia then you're going to end up as a small player in a balkanized internet. That's why all these companies are making aggressive investments and acquisitions in other parts of the world.
CDNs are also part of the fundamental reality of the internet. Could you imagine Netflix or YouTube without CDNs? The amount of network capacity investment necessary to run the internet as we know it without CDNs would cripple it.
And it's not just the internet, but it's a fundamental fact of computing that you have hierarchical caching layers with some data far away and some data closer.
It does, because the definition of bloatness depends on the network speed.
What counts as bloat for an user sitting in Singapore isn't the same as an user sitting in Jakarta.
> Beyond the fact that the network can be mapped (Google surely does this) and simulated
Network topology is irrelevant in this case. The ISP in Jakarta might have a satellite connection to Singapore, but have a CDN and it will load faster than in another ISP with a 10G international fiber link to Singapore.
> All of which is independent of the number and location of CDNs.
That's completely wrong. Today, the vast majority of internet traffic is served from CDNs, CDNs (and their placements) are critical for the internet as we know it.
Simply simulating a globally slowed-down connection will tell you what's going to be a problem. And, really, common sense will tell you what's going to be a problem, too -- if a site "needs" to load 100MB of ads and trackers and other JavaScript to display a couple kilobytes of actual text content, then you have a problem. A user on a slower connection is going to see that site take forever to load even if there's a CDN across the street.
If the problem is a lack of information about global network conditions, then you can deploy canary machines around the world to gather that information.
> If the problem is a lack of information about global network conditions, then you can deploy canary machines around the world to gather that information.
You'd need to put machines in every single city and every single ISP in the world continuously testing every website in the world.
Doesn't make any sense at all. That's not how networks work.
All the hard work of eliminating abuse is something they've done already for those accounts. And their userbase is so big, and presence so strong, that it would generate pressure everyone would benefit from.
My idea doesn't require anything new except them measuring load times, which I'm guessing they're doing already for improving Chrome, and then using this data to influence search ranking. Everything else is already set up and working, and you opt into it if you're using Chrome and are logged in browser-wide.
https://bugs.chromium.org/p/chromium/issues/detail?id=432236
Then you improve your benchmark.
Edit: To clarify, "improve your benchmark" is not a viable strategy by itself any more than "put your opponent in checkmate" is a viable strategy. As advice it is unhelpful. You generally have to mitigate flaws in the way you rank pages, keep large parts of the algorithm secret, and attack the economic viability of your adversary's strategies. Rather than going for checkmate, you want your opponent to resign so you can do something else instead.
There have been incentives for bad behavior on the web for so long that I don't think we have any hope of coming up with any kind of automated benchmark to tell us which pages have good user experience.
If this were true, then there would exist no search engines consistently capable of finding content highly relevant to the user's query -- as opposed to just returning promoted content, which according to your premise is always winning the adversarial battle.
Sure, there is an adversarial element, which means there is a constant 'battle' for 'fairness' among results (or whatever your goals are as a search engine). But in reality, search engines as a whole seem to work rather well at finding what we want. Of course results are biased from adversarial pressures (and that's what we're discussing on this thread), but it does seem possible for "benchmarks" to work well in an adversarial environment.
I can’t tell if you agree that google doesn’t return highly relevant content or if you just get better results than I do. Almost all my search results are dominated by low relevance high click through brands, regardless of quality. For example: quora often replaces high quality content with low quality paywalled answers researched from wikpedia or other public resources. 10 years ago you would have gotten metafilter, which is (imho) objectively a higher quality source less hostile to web users.
The degree to which search engines are gamed successfully by adversaries is not the variable I wish to present a strong opinion of here, which may explain your confusion on my position here.
Instead, I just wanted to illustrate the logical connection between an adversarial-defensive ability to rank based on [website loading speed], and the ability to rank sites based on [any other factors]. If you can pull off adversarial defense of the latter, you probably can achieve the former with even less effort.
That said, I do present to you tentatively the claim that most popular search engines do a decently good job at fulfilling their goals, even if those goals are not in alignment with users' goals in many cases.
For example, there are certainly many examples of paid ads given preferential treatment in search results; however I do not believe this constitutes a case of an adversary beating the search engine's metrics. Rather, it is a consensual relationship/contract between the search engine and an advertiser being fulfilled. Whether this contract/relationship is in the best interest of consumers, is another matter altogether, of course.
You can read it here: https://andrewrabon.com/particle-a-proposal-for-tinier-html-... [Draft]
Would anyone here be interested in seeing the blog post completed and/or helping me build it out? If so drop me a line at andrewrabon at gmail. :)
I also want feedback on if my ideas are actually solving a problem, and are doing so in the correct way. I only recently joined a news publisher so I'm not 100% cognizant of the issues at play.
Hasn't Google gone on record saying that AMP doesn't affect search results given the same page load speed for non-AMP sites?
So yeah, Google's not honest about this.
Disclaimer: I work for Google but not on AMP product.
They'll probably do away with the carousal eventually, but for right now an AMP page does have an advantage in search.
If that's true, and amp doesn't have any preference in the carousal, then Google's comments are completely accurate.
Does anyone actually believe a fancy AMP powered site isn't getting nice traffic boost from Google?
If they were to get a nice traffic boost, would it be because the site actually loads faster or because it was ranked higher. I think both would increase the traffic boost.
It requires changing browsers, to let people distribute Google Hosted Apps on their own domains (as long as Google approves). Sites distributed in this way will get preferential treatment by Google.
This is essentially an App store model, similar to Google Play, and the really big danger is that we end up in a place where you either distribute (and host) your website through Google's AMP registry, or you're not actually on the web (in the same way that distributing your Android app as an APK outside of the Play store is not a realistic distribution channel).
I hope Firefox, Safari and Edge will resist this.
As long as anyone can setup their own AMP-like cache and build a search engine similar to Google, that also supports preloading... then I'm not sure it so bad.
The proposal GP refers to has a lot of use-cases, it basically makes caching of HTTPS by third-parties possible. At-least to some extent.
Yes, anyone could build a cache. But can anyone build a cache that can compete with Google's absolutely massive infrastructure and pile of money, not to mention the reach they already have with search?
I'd say this is not a discussion on the level of ‘can you build a better product and win from a giant company?’, more like ‘can you build a planet and get everyone to move there?’
Yes, the web is dominated by big companies more than ever before but there's at least some competition left.
cloudflare is already doing an AMP-cache. If the specs works out I'm sure other big players might join.
But yes, taking on Google search is hard.
Does it? The web packaging spec linked to doesn't seem to require any of that. And it's intended as an open standard for all browsers to implement, so you wouldn't need to switch.
While the letter wants third-party content not to be surfaced in a wrapping viewport that downplays the fact that it's actually Google's AMP Newsreader, the recent AMP announcement details a planned change where emerging tech [1] will be used to make the URL appear as if the content was directly loaded from the distant origin, because the content being served has been digitally signed by that origin and its serving has been delegated to Google akin to how a run-of-the-mill CDN is delegated the authority to serve content for a domain that's 'spiritually' owned by someone else.
However, the recent AMP announcement does address a very frequent complaint about AMP. Just one that's at odds with the one the letter is requesting.
There could be privacy considerations I suppose, but the standard addresses that already: https://wicg.github.io/webpackage/draft-yasskin-http-origin-...
2. Relies on a "web standard" that Google is pushing and is implementing in Chrome (and so far, I think, only confirmed to be in Chrome)
Update: So after Google announces that they're fixing AMP, some people decided to write a letter demanding that Google fix AMP? I guess the next step will be to retroactively take credit for Google's changes.
[1] https://github.com/amp-letter/amp-letter.github.io/commits/m...
Google's results ordering is already sufficiently "optimized" away from my needs that as often as not I end up in 'verbatim' mode or on page 3 of the results before I get near what I'm looking for, so an extra layer of SEO-gameable "user convenience" isn't likely to make my google experience that much worse.
Since the presence of AMP results is based on device detection, it seems a search setting removing them would be a simple matter. Google's unwillingness to provide it speaks volumes about their actual intent, IMO.
But aren't they the ones creating the content you are enjoying? Seems strange to care so little about them, as without them, there would be no content to enjoy.
And the net will be a better place.
How many publications do you subscribe to?
If my only two options are awful intrusive ads or no content, then I'd choose no content.
Google, please allow me to opt-out of AMP.
Funny because I did the same and stayed with DDG even though Google has slightly better results.
AMP pages have broken controls and I frequently encountered completely broken AMP pages (no content visible). Was this the "fast loading page" experience that AMP promises?
1) Performance - Yes, it LOADS fast, but MANY pages "feel" janky, when scrolling, especially pages that allow you to load additional accords by scrolling left/right. Only the simplest pages don't "jank" on my device.
2) Scrolling - It isn't the native scroll. It seems to be a div with "overflow-scrolling" applied. Other than that feeling "off", it prevents the bottom toolbar from hiding, reducing screen real estate.
3) Sharing URLs.
4) Biggest: No way to opt-out. I'm a fan of the open web. It's why I prefer a website to a sandboxed experience you get with native apps. At least for the first click on Google SERP pages, I'm "stuck" with google.com.
One note: I get the AMP use case, and I'm sure there are users who prefer AMP pages for the performance they see. However, I'm fortunate enough to live in an area with decent mobile speed/bandwidth, and loading the original pages are rarely "slow" on my device. However, the originals all address the issues I noted above. I'll take the .5-1 second delay for the original(s), over the AMP version.
I’ve been in mobile development for about a decade, what Google did was re-invent WAP on top of HTML5, turning back the clock at least 10 years.
By also sending all non-Google traffic through the tunnel ("for improved speed!" remember when AOL included SpeedBooster Technology?) they'd control a majority of all non-search internet traffic, like AOL without the disks. And they wouldn't even have to bill you because they'd get an unlimited supply of ad data.
Aside: from a privacy perspective it creeped me the hell out once I realized what was happening.
2) Touching tap to return to the top of a webpage is broken.
3) Searching for a word within a webpage is broken.
This is all basic functionality that I use often. And I'm sure there are other things broken about it.
Dear website owners who wrote this letter: yes, amp has it's downsides but the reason we have amp is that the internet as a whole failed to make fast sites. you had your chance for the previous ~30 years, and it's clear you couldn't be bothered to make speed a priority. I'm glad you're angry that AMP is eating your lunch, because maybe you'll actually start trying to compete now. But you aren't getting my sympathy.
I'd probably have a different opinion if I didn't use Adaway, which blocks ad servers by domain in /etc/hosts. When I've tried going without an adblocker, the web was not such a nice place.
Half of the reason we're in this mess is on-line advertising. The other half is that lots of companies think it's a great idea for everything to require constant data exchange with the cloud.
And now they’re trying to get a new standard feature to let them lie about the URL to make it even easier!
You know what worked well? 20+ years of the URL bar showing me the site I was trying to read without bikinis messing with it.
Also, that was added later. Originally it wasn’t there at all.
And the benefit of everybody with a mobile device that just wants their article to load quickly.
> And now they’re trying to get a new standard feature to let them lie about the URL to make it even easier
These are called "engineering tradeoffs". It's not perfect, but it's better than what we had before.
Google could allow opt out of AMP for all those who don't want it in their search results but they don't because they are trying to wall off and control a section of the web.
If AMP and others exist, there's a reason, and it might be more useful to respond to that than to respond to AMP.
That’s not a reason that matters to me at all.
Fast websites stayed fast, and slow websites stayed slow. They also gave out tons of free "speed test" tools to make it easy for developers to test their speed, and improve it. They even made apache and nginx plugins that would auto-optimize assets as it served them! And still basically nobody used them.
Plus it's not just about "faster than XXXms". What is that time measured to? Time to text on the screen? Can they game it by lazy-loading images, then videos, then ads, then 6mb of other javascript and social networking stuff and a comment system and...?
You could try a "size limit", but then you penalize asset heavy sites (like high-resolution image sharing sites, or video sites).
So their solution was to make a very restrictive system where you are forced to do things "the right way" (for at least one definition of "right"), and to pump that up in the search results.
Plugins were made for common blogging and news platforms, and now a portion of the web loads significantly faster for many, and I think that's a win.
It's not perfect, but it's at least the first thing that I've seen google try in this area that is actually working.
Obviously there is benefit to Google as a company in that now results that are served through their AMP system are faster than those of some of their competitors, and AMP gives them a nice easy way to pull some structured information from an article for things like the carousel or other non-search offerings, but I genuinely don't believe that was the main motivator, seeing as Google has years of examples of failed attempts to "fix" this problem (though maybe I'm just not cynical enough!).
That being said, there are technical reasons why this hasn't happened yet. The good news is that some web standards (ex: https://wicg.github.io/feature-policy/) are being worked on that would (hopefully) allow Google to verify performance of sites without relying on AMP.
This would give Google no excuse to give AMP content special treatment, and would hopefully relegate AMP to what it should've been since day one: a framework for performance, but one that wasn't required or bolstered by any Google-colored carrots.
> The developer may want to use the policy to assert a promise to a client or an embedder about the use—or lack of thereof—of certain features and APIs. For example, to enable certain types of "fast path" optimizations in the browser, or to assert a promise about conformance with some requirements set by other embedders - e.g. various social networks, search engines, and so on.
You're right that there's more to it though.
Website did ridiculous things for SEO when Google was the main traffic-driver on the web. Ridiculous. If Google sufficiently penalized bloat in ranking most websites would remove the bloat. But it never was a significant enough factor.
IIRC they treat AMP pages the same as any other in terms of ranking, but since AMP is super fast, it gets a natural boost.
(obviously AMP gets other benefits like the lightning bolt badge and inclusion in the carousel)
https://search.googleblog.com/2012/01/page-layout-algorithm-...
The caveat comes in when no alternative exists, and when the access to some information of service on very constrained connections (such as you'd see in remote third-world regions with poor Internet access) meets some reasonable definition of vital, but I've not seen where AMP is playing a significant part in that.
For example, Reddit loads extremely fast, and AMP pages are absolute shit, I don't know why they decided to use it.
And I'd rather view the website as intended (minus the ads, sorry), than in a shitty cut down version that takes 3 seconds less to load.
Loading a traditional site can have side effects (e.g. reporting a view to an advertiser's analytics). By using the AMP validator, Google Search knows it's safe to preload and prerender an article, without triggering side-effects like analytics.
So it's more than just loading faster than some threshold; it needs to be safe to cache and prerender the content. The AMP validator is what asserts these are both safe.
(Note, I don't work on AMP and don't represent Google - this is my personal understanding.)
[0] Ilya Grigorik's time-to-glass talk https://www.youtube.com/watch?v=Il4swGfTOSM
https://medium.com/reloading/preload-prefetch-and-priorities...
The narrative of wanting to monopolize user traffic doesn't make much sense in light of the recent announcement around URLs.
I think a lot of this is in reaction to FB's Instant Articles and wanting to gain further leverage over publishers. If you can commoditize publishers' content and control the format, and you supply the users and the monetization via ads, you can make the publishers do whatever you want because the alternative is for them to lose money, which they can't afford to do.
In many ways, this is a very defensive play by Google. It also happens to provide a better user experience in some ways, which is awesome, and also helps further Google's goals of controlling ad formats and more importantly the data that is collected on publisher sites that lets them monetize their data in ways they may not be able to with AMP pages.
AMP only works today because it's re-hosted inside the origin (google.com), so much that in order to fix this in the future, they'll have to rush out a new web standard and implement it in chrome (and hope other browsers do the same:) https://amphtml.wordpress.com/2018/01/09/improving-urls-for-...
Move ad blocking to the indexing layer. Create a corner of the web that is naturally fast and user-friendly again without resorting to corporate-defined subsets of well-documented open web technologies.
My experience has been that direct-sold ads produce more revenue for publishers than programmatic ads. I would love to see research on this one day.
Yes, but do they provide an equally good ROI for advertisers? (And the same level of granularity, tracking and reach as something like Google Adwords?) That's the real issue at play.
Uh, usually this results in "native advertising", which is advertising pretending to be real articles. This is much more dangerous and insidious in my opinion than an explicit 'sponsored' box with an ad inside.
If this continues, successful publishers will be the ones that push the most profitable corporate propaganda, rather than the ones that effectively inform the public.
Sorry, I'm trying to be as succinct as possible, but I've come to see the advent of ad blockers, intrusive ads, pervasive tracking, client-heavy web practices, and clickbait as a single phenomenon that has its roots in the rise of CPM as the primary pricing mechanism for advertising.
Then you should join the distributed free p2p search engine: http://yacy.net
Long story short 100/100 with page speed is possible with most sites; further optimize for Speed Index by using rel="preload" for assets above the fold. What else am I missing?
People are trusting us to help them with technical decisions and we have a responsibility to make sure the web is accessible to as many people as possible. Our opinions have tremendous sway, even though it might not feel like it.
The web really started to go sideways when we followed the trend away from Progressive Enhancement. Let's get back to basics, pure and simple.
I completely agree about unnecessary annoyances such as auto-playing video, or load-blocking ads. #perfmatters.
1. click from the search page to the search result AMP page
2. click on a link on the AMP page to see the original link
3. click on the original link to bring the original search result
Also, they have Real user data for over a million websites - https://developers.google.com/web/updates/2017/12/crux
This is a way better indicator of site speed as opposed to if the site is AMP or not. Would be so cool if Google used this data as a pre condition to put sites into the carousell!
It devalues the letter, in my opinion, because I see them as people signing the letter for the sole purpose of promoting themselves.
But like I said...maybe I'm being too cynical.
Show AMP results for all browsers. AFAIK, only Chrome (and maybe Safari, can't confirm) are shown AMP links in the search results.
There is people (like me) who like to support other browsers , or like some addons. I get it, Google: you want your browser to be the most popular. You've done it. Now treat the rest of them like capable pieces of software.
None of these platforms value add much that can't be built into whatever the next web becomes... But no organization is as powerful as a single one of them.
So Google is allowed to do this as long as all these other companies do what they are doing. I think what happened is that all the other disruptions were done to companies that don't know something could be better - they were not technologists, programmers, etc..
This letter is written by technologists, developers, so they know what google has done to steal the market. But no one here wants to apply the same logic to the other ones.
News committed to an anonymous blockchain, immutable and potentially monitizable seems pretty interesting but maybe not as lucrative as other ideas.
Because AMP isn’t about ads or speed, it’s about editorial control. The same goes for Facebook and Apple.
I don’t care how many press releases they put out denying it.
https://blogs.bing.com/search/September-2016/bing-app-joins-...
I'll take 500ms page loads any day when the content comes from the true origin. I don't want 60ms responses from a Google server when I'm trying to use the internet.
Why not just make google the internet?? There's power and freedom to be had when publishers aren't tied to a tech behemoth.
If a page has AMP version, it redirects mobile users to AMP version, but on that page, not on its own cached version.
Is AMP opt-in for site owners? Or is it determined by page load speed? It didn't use AMP for my website, but it also loads faster than google.com ¯\_(ツ)_/¯
A letter about Google AMP
We are a community of individuals who have a significant interest in the development and health of the World Wide Web (“the Web”), and we are deeply concerned about Accelerated Mobile Pages (“AMP”), a Google project that purportedly seeks to improve the user experience of the Web.
In fact, AMP keeps users within Google’s domain and diverts traffic away from other websites for the benefit of Google. At a scale of billions of users, this has the effect of further reinforcing Google’s dominance of the Web.
We acknowledge the problem of Web pages being slow to load, relative to alternative, proprietary technologies such as Facebook Instant Articles and Apple News. Publishers (especially in news media) have long faced difficult choices and poor incentives, leading to bad decisions and compromises, and ultimately to terrible user experiences.
Search engines are in a powerful position to wield influence to solve this problem. However, Google has chosen to create a premium position at the top of their search results (for articles) and a “lightning” icon (for all types of content), which are only accessible to publishers that use a Google-controlled technology, served by Google from their infrastructure, on a Google URL, and placed within a Google controlled user experience. (source)
The AMP format is not in itself, a problem, but two aspects of its implementation reinforce the position of Google as a de facto standard platform for content, as Google seeks to drive uptake of AMP with content creators:
Content that “opts in” to AMP and the associated hosting within Google’s domain is granted preferential search promotion, including (for news articles) a position above all other results. When a user navigates from Google to a piece of content Google has recommended, they are, unwittingly, remaining within Google’s ecosystem. If Google’s objective with AMP is indeed to improve user experience on the Web, then we suggest some simple changes that would do that while still allowing the Web to remain dynamic, competitive and consumer-oriented:
Instead of granting premium placement in search results only to AMP, provide the same perks to all pages that meet an objective, neutral performance criterion such as Speed Index. Publishers can then use any technical solution of their choice. Do not display third-party content within a Google page unless it is clear to the user that they are looking at a Google product. It is perfectly acceptable for Google to launch a “news reader”, but it is not acceptable to display a page that carries only third party branding on what is actually a Google URL, nor to require that third party to use Google’s hosting in order to appear in search results. We don’t want to stop Google’s development of AMP, and these changes do not require that. We also applaud search engines that give ranking preference to fast-loading pages. AMP can remain one of a range of technologies that give publishers high quality options for delivering Web pages quickly and making users happy.
However, publishers should not be compelled by Google’s search dominance to put their content under a Google umbrella. The Web is not Google, and should not be just Google.
Sincerely, AS INDIVIDUALS
<long list of names>
* Accelerated Mobile Pages: https://ampproject.org
* Facebook Instant Articles: https://instantarticles.fb.com/
* Apple News: https://developer.apple.com/news-publisher/
* source: https://developers.google.com/search/docs/guides/about-amp
* Speed Index: https://sites.google.com/a/webpagetest.org/docs/using-webpag...
Look at the underlying specs... They are talking about bundling web packages and signing them with TLS certificates, so that anyone can distribute them... and the browser can still verify the origin.
"You don't need AMP to make websites fast!"
And yet, most popular websites sans AMP were/are indeed quite slow.
1. Optimize the content we deliver, (HTML, CSS, JS, etc...). Minimise the time for all content and First Meaningful Paint.
2. CDN servers. Bring the servers closer to the user, geographically.
3. File compression during transport. Stuff like gzip and HTTP/2.0 (which isn't a compression algo, but inherently makes the pages load faster, which was the objective)
Edit(s): Some formatting & content, somewhat new to HN
AMP got (some) websites to actually be fast, which is a lot more useful than a hypothetical.
The AMP spec is about speed, that doesn't require being served from a google.com domain. If there are speed benefits to caching by google, why make that mandatory?
I was perfectly able to make my personal website fast; there is no problem, no one needs AMP.
The kick in the pants was really Google throwing their weight around something which could have been done in a number of different things. Hell Google could have charged to use their CDN in exchange for totally not favorable ranking and an icon and raked in the cash.
To draw a crude analogy- I don't have a problem with alcohol, I don't drink in excess and that's all there is to it. So clearly, there's no reason for AA or any other detox program to exist.
That's a much better method than pushing sites to use a shitty lock-in system.
Early 2000s we had crappy Flash Websites that took a minute to load. I refused to build websites with Flash and would only build websites that were HTML and JavaScript (I HATED JS back than (Maybe it was just me)). I stopped getting business because that norm was slow websites that were pretty and had animations.
After Mobile took off in the early 2010's we had faster connections and those Flash sites worked much faster, except for mobile. Now everything is responsive and 2 or 3 seconds feels like a lifetime.
AMP changed the internet in my opinion, and maybe it isn't needed any more.
AMP serves a purpose for the end user and it does so well, it loads instantly and doesn't consume much data in the process.
As for their "demands":
1. Google already states that AMP pages are ranked higher because they're faster to load.
2. I'm not sure if it's related but they they addressed that only yesterday: https://amphtml.wordpress.com/2018/01/09/improving-urls-for-...
E.g., your site is just as performant as AMP, but you're not using AMP.
I'm of the persuasion that they can rank and display the results however they please, it's their site after all, so it's a non issue either way.
Hmm, I guess it depends where you look. I saw quite a LOT of people upset by it. Many participated because they felt like they had to in order to get views.
Cool, so how do I get my plain text page which loads faster than the motherfuckingwebsite.com into the AMP carousel?
If anything, supporting AMP has accelerated my non-AMP pages a lot.
On the bright side, every time it happens, it reminds me that news is rarely worth reading and that I should spend less time on Google News.
You could argue that a browser could preload Google search results before you click them, but: (1) those pages could be giant, and loads 10 giant pages would be a bad bandwidth tradeoff and (2) there are privacy implications, since this would leak information about what users are searching for, even if they don't click the results.
This is wrong. Google can proxy the traffic like they do with Gmail, negating that privacy issue.
I was typing a comment in which I said that I'd prefer your privacy risk (where I leak info to random sites that I might want to visit anyway) over the current privacy issue (all sites using AMP leaking data about me to Google), but it's worse than that: the risk you identify is easily mitigated by proxying the content.
The other risk you mention is not as easily mitigated. Proxying might help in part, because then the servers can be selective and/or stop at a certain point. Another idea is to only preload the HTML, and perhaps a limited number of resources smaller than a certain size (mainly css and small-size images, since JS is usually not used in styling, so preloading html and css should give a first, static impression before the rest can be loaded).
All of this would have been better than any part of what they chose. I can see only two reasons for Google not to choose this: (1) more control over the web (this I think is true) and (2) more tracking (this I think a few people within Google might see as a nice side-effect, even if the vast majority of employees has only good intentions, so I don't think it was a driving reason but it probably contributed).
And that is the simplest definition of AMP: a set of rules to define an efficiently presented news article. and then the continuation of that is that if a news article follows those rules, it is cache-able and google can give it a significant speed boost by serving it from their cache.
* Idle Words http://www.idlewords.com/ (while we're on this topic, http://idlewords.com/talks/website_obesity.htm is worth reading)
* Programming In the 21st Century http://prog21.dadgum.com/
Are both extremely fast, filled with interesting content and amazingly manage this without loading any javascript from a google domain.
"You don't like that Comcast is going to decide what sites you can see? Then make your own ISP"
"You don't like that the water company is pricing people out of drinking water? Make your own water utility"
"You don't like that Golden Gate jacked their prices? Build your own bridge"
BTW, those examples aren't exaggerations. I imagine they're all no less difficult than making a new search engine to compete with Google.