3 ms·

> The letter calls on the AMP team to make two primary changes: > Instead of granting premium placement in search results only to AMP, provide the same perks t

> The letter calls on the AMP team to make two primary changes: > 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. How would you measure this in a way that couldn't be gamed? I'm not saying AMP is the best solution, but the way AMP prevents you from doing things that hurt performance makes it much easier for you to know for sure an AMP page has certain performance properties.

tkadlec 9y ago
First off, you're right: any metric can be gamed. Even so, Google is already using performance to factor into its algorithm, so some level of reasonable accuracy must have already been agreed upon. Ensuring a certain level of performance is not a very easy problem to solve. But it's doable. Myself and a few others sat down with the AMP team awhile back and chatted about what that would look like and there were definitely a few different layers that would be needed to get it to work. The first is already in progress. There's a spec for something called "Feature Policy" (https://wicg.github.io/feature-policy/ https://wicg.github.io/feature-policy/). Feature Policy would let you tell the browser you don't need certain features which would in turn let browsers take shortcuts (so to speak). For example, you could declare that you will not be allowing document.write. Enough features being declared could serve as a way for Google (and others) to say "Ok, this is going to be reasonably fast." There's more needed of course: we had discussions about a standard related to declaring a limit on asset sizes, etc. But it's a start. And while it will always be a little fuzzy, the same is true of AMP. It's completely possible to build a slow AMP page. The best Google can do is say "if they're doing X, then the odds are good that it's performant".
- seanwilson 9y ago
  > Ensuring a certain level of performance is not a very easy problem to solve. What I'm getting at is maybe AMP is Google's way to make the problem easy. Sometimes when a general problem is difficult, you're better adding restrictions to make the problem tractable. > It's completely possible to build a slow AMP page. Can you elaborate? How easy would it be to test AMP pages for that?
  - tkadlec 9y ago
    > What I'm getting at is maybe AMP is Google's way to make the problem easy. Sometimes when a general problem is difficult, you're better adding restrictions to make the problem tractable. It absolutely is! (Sorry if I made it sound like it wasn't). That's what the goal is of Feature Policy and other standards too: to add restrictions to make it easier to solve. > Can you elaborate? How easy would it be to test AMP pages for that? I keep meaning to make an example, but real work gets in the way. :) Basic gist though is that AMP is, again, only a fuzzy approximation of good performance. You can still mess it up. As for testing, the best thing to do is probably test from the origin server. That way you eliminate the Google cache layer and just focus on what the format itself actually accomplishes. There was a post recently where a guy did exactly that, and the results were far from instant: https://ferdychristant.com/amp-the-missing-controversy-3b424031047#8e10 https://ferdychristant.com/amp-the-missing-controversy-3b424... The conclusion, for anyone who doesn't want to click through, is that the vast majority of the performance benefits don't come from AMP itself. They come from A) the Google cache layer and B) the fact that Google preloads the AMP page in the background before you click on it.
    - seanwilson 9y ago
      Interesting, thanks for the link! Not sure I agree with this part though: > What we know about AMP is that the technical standard in itself enforces good performance. For example, CSS is limited to 50KB and only inline, custom JS is not allowed (other than via an iframe method), and all images are guaranteed to be lazy loading. Hence, this is why AMP pages load instantly compared to a “normal” web page. It’s enforced by the standard. Right? Wrong. If you're including several MBs of CSS and JS in a render blocking manner and even more MBs of non-lazy loading images (which really isn't unusual) you're going to have a significantly slower page. There's a lot of hate for AMP but those restrictions make a lot of sense.
zbentley 9y ago
This might be a somewhat controversial (or just reviled) opinion, but: why should search engine rankings care about page performance? As soon as Google, the thing that indexes for relevance starts caring about an orthogonal behavior like performance, my ability to trust that I'll see relevant things first is compromised. Balancing between two good criteria dilutes both, basically. Performance impacts a page's relevance in one case: if it never renders (times out), in which case it isn't indexable anyway. Otherwise, users have "stop" and "back" buttons at their disposal if a relevant page doesn't load fast enough for them. Performance is important, but should not be a criterion for search results. The fact that it's may be incorporated into the ranking system is at best extremely misguided and at worst baldly avaricious.
- seanwilson 9y ago
  > This might be a somewhat controversial (or just reviled) opinion, but: why should search engine rankings care about page performance? They'll care because faster results will generally mean happier and more engaged users who'll want to use your search engine again. This applies even more for mobile users where you might be waiting 10s of seconds before anything is rendered on a slow page.
  - zbentley 9y ago
    That concerns me, if true. If users will blame the search engine for directing them to a page that is relevant yet slow, and the logical solution to that is that the search engine should ensure all pages are fast, doesn't that open up a bit of a can of worms about the search engine itself? I.e. if users blame the search engine for providing results for "whose religion is the best" that they disagree with, wouldn't the same logic incentivize the search engine makers to filter those results for users whose religious preference is known? It seems like a bad tradeoff to make: marginally increase user engagement by serving faster pages at the cost of potentially compromising the primary reason (relevance) that people use your search engine? I'm sure there is data supporting that decision, but this doesn't make it sit any better with me. It's like going to the library and saying "I'd like the complete works of Shakespeare, please" and having the librarian say "well, here's our theater section, but please pay special attention to these abridged/easy-reading versions of Shakespeare, since we think they'll make for a more enjoyable experience for you. The complete works are on this floor somewhere; you can find them yourself." I'm not saying that we'll automatically slide down that slope, just that it's there, and a bit slippery.

tkadlec 9y ago

First off, you're right: any metric can be gamed. Even so, Google is already using performance to factor into its algorithm, so some level of reasonable accuracy must have already been agreed upon. Ensuring a certain level of performance is not a very easy problem to solve. But it's doable. Myself and a few others sat down with the AMP team awhile back and chatted about what that would look like and there were definitely a few different layers that would be needed to get it to work. The first is already in progress. There's a spec for something called "Feature Policy" (https://wicg.github.io/feature-policy/ https://wicg.github.io/feature-policy/). Feature Policy would let you tell the browser you don't need certain features which would in turn let browsers take shortcuts (so to speak). For example, you could declare that you will not be allowing document.write. Enough features being declared could serve as a way for Google (and others) to say "Ok, this is going to be reasonably fast." There's more needed of course: we had discussions about a standard related to declaring a limit on asset sizes, etc. But it's a start. And while it will always be a little fuzzy, the same is true of AMP. It's completely possible to build a slow AMP page. The best Google can do is say "if they're doing X, then the odds are good that it's performant".

seanwilson 9y ago
> Ensuring a certain level of performance is not a very easy problem to solve. What I'm getting at is maybe AMP is Google's way to make the problem easy. Sometimes when a general problem is difficult, you're better adding restrictions to make the problem tractable. > It's completely possible to build a slow AMP page. Can you elaborate? How easy would it be to test AMP pages for that?
- tkadlec 9y ago
  > What I'm getting at is maybe AMP is Google's way to make the problem easy. Sometimes when a general problem is difficult, you're better adding restrictions to make the problem tractable. It absolutely is! (Sorry if I made it sound like it wasn't). That's what the goal is of Feature Policy and other standards too: to add restrictions to make it easier to solve. > Can you elaborate? How easy would it be to test AMP pages for that? I keep meaning to make an example, but real work gets in the way. :) Basic gist though is that AMP is, again, only a fuzzy approximation of good performance. You can still mess it up. As for testing, the best thing to do is probably test from the origin server. That way you eliminate the Google cache layer and just focus on what the format itself actually accomplishes. There was a post recently where a guy did exactly that, and the results were far from instant: https://ferdychristant.com/amp-the-missing-controversy-3b424031047#8e10 https://ferdychristant.com/amp-the-missing-controversy-3b424... The conclusion, for anyone who doesn't want to click through, is that the vast majority of the performance benefits don't come from AMP itself. They come from A) the Google cache layer and B) the fact that Google preloads the AMP page in the background before you click on it.
  - seanwilson 9y ago
    Interesting, thanks for the link! Not sure I agree with this part though: > What we know about AMP is that the technical standard in itself enforces good performance. For example, CSS is limited to 50KB and only inline, custom JS is not allowed (other than via an iframe method), and all images are guaranteed to be lazy loading. Hence, this is why AMP pages load instantly compared to a “normal” web page. It’s enforced by the standard. Right? Wrong. If you're including several MBs of CSS and JS in a render blocking manner and even more MBs of non-lazy loading images (which really isn't unusual) you're going to have a significantly slower page. There's a lot of hate for AMP but those restrictions make a lot of sense.

zbentley 9y ago

This might be a somewhat controversial (or just reviled) opinion, but: why should search engine rankings care about page performance? As soon as Google, the thing that indexes for relevance starts caring about an orthogonal behavior like performance, my ability to trust that I'll see relevant things first is compromised. Balancing between two good criteria dilutes both, basically. Performance impacts a page's relevance in one case: if it never renders (times out), in which case it isn't indexable anyway. Otherwise, users have "stop" and "back" buttons at their disposal if a relevant page doesn't load fast enough for them. Performance is important, but should not be a criterion for search results. The fact that it's may be incorporated into the ranking system is at best extremely misguided and at worst baldly avaricious.

seanwilson 9y ago
> This might be a somewhat controversial (or just reviled) opinion, but: why should search engine rankings care about page performance? They'll care because faster results will generally mean happier and more engaged users who'll want to use your search engine again. This applies even more for mobile users where you might be waiting 10s of seconds before anything is rendered on a slow page.
- zbentley 9y ago
  That concerns me, if true. If users will blame the search engine for directing them to a page that is relevant yet slow, and the logical solution to that is that the search engine should ensure all pages are fast, doesn't that open up a bit of a can of worms about the search engine itself? I.e. if users blame the search engine for providing results for "whose religion is the best" that they disagree with, wouldn't the same logic incentivize the search engine makers to filter those results for users whose religious preference is known? It seems like a bad tradeoff to make: marginally increase user engagement by serving faster pages at the cost of potentially compromising the primary reason (relevance) that people use your search engine? I'm sure there is data supporting that decision, but this doesn't make it sit any better with me. It's like going to the library and saying "I'd like the complete works of Shakespeare, please" and having the librarian say "well, here's our theater section, but please pay special attention to these abridged/easy-reading versions of Shakespeare, since we think they'll make for a more enjoyable experience for you. The complete works are on this floor somewhere; you can find them yourself." I'm not saying that we'll automatically slide down that slope, just that it's there, and a bit slippery.