AMP is just a set of conventions and limitations that, when followed, make for a fast site. Anyone can make a fast site if they follow similar rules. Most sites don't do that because either the developers want to use something that's "nicer" to code but a lot bigger, or because the marketing department insists on loading 12 different tracking and analytics progams--when they probably only use one or two.
They could also just have mandated serving AMP with some random HTTP header and the client would cached a whitelist of the AMP scripts if got that header, nothing in the AMP design needs to have an AMP server, it's an arbitrary limitation from Google to control the web.
I didn't say, "they could guarantee the time it takes to load for every user on every connection on every browser".
I said "they could simply measure the load time of a site when they index it." Their indexer, running from their servers could be their "reference point" for this content.
It feels like AMP is Google nailing its own coffin to me. It probably felt like a winning move when Bell and AT&T made people buy their own products to use telephone systems, but it led directly to their disruption by the DOJ. Even though some poeple at Google probably realize that, it won’t matter if they cash out beforehand, if working on a project gets them promoted, and if institutional inertia is in control.
Google is hurtling toward an antitrust case they won’t win, and it will really be all their fault.
Throwaway Google search engineer here. People here really do care about making the web faster and moving metrics, both because that is how the company is set up to reward employees but also because they believe it makes the product better.
Google has been penalizing slow sites forever. It stopped moving the needle (I suspect because it isn’t marketable). Amp on the other hand really is working, metrics show a faster, smoother experience, and user studies have been positive. That’s why Google is doubling down so much with it. Not because they have goals to control content providers or wall off the web, but because it makes a dramatic difference on the whole.
So if the "only" goal of AMP is to make things faster, why isn't the carousel based purely on "your result must load in < X ms"? If a company can "force" other companies to adopt AMP, it can surely "force" them to improve load times on their own.
Also, if speed is their goal, why does the mandatory AMP 'boilerplate' include a CSS-driven 8 second delay before content is shown, that is removed if the client loads the AMP JS?
Oh right. I know the answer. It's to give the impression that blocking third-party resources (such as AMP JS) via e.g. a content blocker, won't make the site faster. Which as we know, is a load of shit.
You might have the best of intentions and donate your entire salary to homeless blind children - that doesn't mean for a second that I believe google's actual goals with AMP are anything less than exerting more control over the web for their own purposes.
You should stop and do some serious research on why people don't like AMP. You're talking about the Web like it's a Google "product." You're hijacking the Web in a way that will eventually destroy it.
Publishers don't want their content restricted and hosted on Google's servers on Google's domain, but they are getting their arms twisted by reduced rankings if they don't implement it. They also don't fully understand the long term implications of what they are doing.
Sure, but one of those conventions and limitations is that the page is hosted by google. It's not something you can deploy on your own server. It's not as if it's just some list of recommendations that make sites faster - you're signing up to a Google service, and you're at their mercy from then on.
>It's not something you can deploy on your own server.
But you can. Often it doesn't matter because you aren't a globally distributed cache, but if you are cloudflare[1] (or apparently Microsoft[2]), you can and do.
For example, you can't use an img tag on an AMP page. That's invalid AMP. You have to use an amp-img tag, which is rendered client side with js.
Another example is with forms. It forces you to include the amp-form js.
If it were just best practise, I'd be far happier to go along with it. Kind of the point here is that we were already using best practise, because the site was super fast.
This allows AMP to skip preloading images below the fold on viewports of arbitrary size. If you fired somebody for doing something you don't understand without asking for an explanation, that's your problem.
Impossible. For a site loaded from a SERP, the page will be preloaded if it is AMP. If you are creating an AMP page to be accessed directly (like the author), you fundamentally don't understand the problem that AMP solves and are using it wrong. PEBKAC.
It's about control of preloaded content, specifically. If you don't care about your content being easily preloaded from the SERP page, then sure, no need to use AMP. And if, as a user, you don't care about quick access to preloaded content (because e.g. you're on a low-latency connection), feel free to scroll down from the top-stories carousel.
Preloading is a waste of data on mobile. If you're on a metered connection then this costs more. Ranking sites by performance would already ensure a fast UX for users.
Also position on the SERP page is a major indicator of relevancy. Biasing results because they use AMP is unfair and inaccurate.
