5 ms·

Is there a reason you can't just build the site properly in the first place to load fast? AMP is an unnecessary step in doing so. It's nothing special. All AMP

by kup0 11y ago

Is there a reason you can't just build the site properly in the first place to load fast? AMP is an unnecessary step in doing so. It's nothing special. All AMP is, is a decided-upon set of restrictions for what you can do on a page. If you follow those same restrictions with normal HTML/CSS you can achieve the same results. I've never understood the use of AMP, just build your normal site properly in the first place and then you won't need it. It's almost like training-wheels for learning efficiency/optimization.

Touche 11y ago
"If you just don't step on the mines, you can walk through a minefield and live".
tmaly 11y ago
I totally agree. I have been back and forth on using bootstrap with CDN verse just plain simple css. I did a test with bourbon.io this morning to make a simple page with the responsive navbar. The resulting css file was just 1 kb compressed. That is a huge improvement over these heavier frameworks. A major con against AMP in my opinion is that it is something else to learn on top of everything.
frandroid 11y ago
Good developers can make fast sites (though that's not a given!!), but product managers will absolutely bloat your site. "Add this third tracking/analytics tool"; "Add this custom ad format here"; "Oh this partner will give us tons of money if we put this widget on the page"; "Oh let's use Brightcove video player"; "Oh let's auto-play videos"; "drive-by A/B testing"; "We don't control this third-party 2MB image", "The widget streams a 23MB .WAV file for background music that only auto-plays in mobile"; "Why build this in-house when we can just use this good third-party library?"; "Good third-party library costs too much, let's use this horrible but much cheaper one instead"; etc. AMP allows you to tell your product manager: "Sorry! Not supported." Of course, with enough responses like this, a decision eventually comes down to not use AMP.
- tmoorai 11y ago
  OMG, what kind of product managers do you know. A good one would never ask for such things...
  - frandroid 11y ago
    The problem is that I don't work for a tech company, and the product managers have their own silly non-product managers. :) X(
- tripzilch 11y ago
  > AMP allows you to tell your product manager: "Sorry! Not supported." I like this reason. It's both a good reason for AMP to exist (albeit to solve a sad problem, with the product managers), as well as to justify not using it myself :-) > Of course, with enough responses like this, a decision eventually comes down to not use AMP. Perhaps. But having an external set of guidelines that relate to an all-or-nothing benefit (inclusion in Google's AMP program) seems helpful to me (from the eye of a developer who cares about bloat). A small team of good developers could also formulate their own set of guidelines in order to avoid bloat and achieve fast loading. But those guidelines will have to be guarded by the developers against "political" forces, and there's a distinct possibility that more and more compromises will be made. Exclusion from the AMP program provides a line in the sand, so to say.
wffurr 11y ago
You are correct, but beg the question: why are so many popular websites so slow even if they are essentially static content? If putting a brand on a set of techniques plus offering CDN space and serp priority gets publishers to actually build fast websites, then I am all in favor of it.
- tripzilch 11y ago
  One reason (but not the whole reason) is that trackers are always essentially dynamic content.
mseebach 11y ago
> I've never understood the use of AMP, just build your normal site properly in the first place and then you won't need it. It's almost like training-wheels for learning efficiency/optimization. I've never understood why toddlers need training wheels on their bikes? Why don't they just bike properly in the first place?
- kup0 11y ago
  If your view is that web developers working for publishers are "toddlers" in their industry, then I suppose this comparison is apt. I guess the only oversight I see in my original post is that most of the time, the webdevs aren't the ones with the final say anyway and maybe branding the restrictions will make it more palatable to publishers. It's just sad that we're at the point where it has to be done this way. But it is telling that publishers are fine with being restricted by AMP, when they could have implemented those restrictions extremely easily on their own instead of having to be hand-held through the whole thing. The other issue I have is that it's generally intended for mobile only. If the site was built for speed and efficiency from the ground up, it would be a fast experience everywhere
ageitgey 11y ago
"All AMP is, is a decided-upon set of restrictions for what you can do on a page". You say that like it's a bad thing! But that's the entire point. Without a clear set of rules, almost no one makes fast pages in real life. This is especially true when you are working in a company where a wide mix of people have competing objectives. The developers want a fast page, the designers want a pretty page, the PMs want conversion, the business folks want lots of ads, etc. It makes it nearly impossible to build something fast without clear rules. Take a random article on the TheVerge.com as an example. I'm sure they have fantastic web developers who want the site to load quickly and they definitely know how to build beautiful pages. But check out their normal responsive page you get if you visit their site directly on your phone: http://www.theverge.com/2016/3/15/11233030/jj-abrams-moon-shot-review-google-lunar-x-prize-documentary http://www.theverge.com/2016/3/15/11233030/jj-abrams-moon-sh... Using Chrome's "Regular 2G" throttling, that page takes 19.82s to hit DOMContentLoaded and an insane 1.3 minutes to hit Load. The total mobile page weighs 2.5mb! Now check the AMP version of that same page. You can find it by looking for the 'link rel="amphtml"' tag in the header of the page: http://www.theverge.com/platform/amp/2016/3/15/11233030/jj-abrams-moon-shot-review-google-lunar-x-prize-documentary http://www.theverge.com/platform/amp/2016/3/15/11233030/jj-a... Using the same Chrome throttling settings, it hits DOMContentLoaded in 802ms and Load in 33.33s. And even then, almost all of that time is spent loading fonts and (in this particular article, very poorly optimized) images. To a mobile user, that is a way better experience - the difference between bouncing and reading. And the only difference was having "a decided-upon set of restrictions".
- kup0 11y ago
  As a desktop user, that is a way better experience too, but because AMP seems to be mostly mobile-focused, we desktop users get the "normal" experience typically. If the site was built from the beginning with performance in mind, we'd all benefit, no matter what we're using to view the site. I get that it has more to do with business side of things vs. the development side of things. Lots of hands in the pot at these companies and webdevs are only one part of it.

by kup0 11y ago

Touche 11y ago

"If you just don't step on the mines, you can walk through a minefield and live".

tmaly 11y ago

I totally agree. I have been back and forth on using bootstrap with CDN verse just plain simple css. I did a test with bourbon.io this morning to make a simple page with the responsive navbar. The resulting css file was just 1 kb compressed. That is a huge improvement over these heavier frameworks. A major con against AMP in my opinion is that it is something else to learn on top of everything.

frandroid 11y ago

Good developers can make fast sites (though that's not a given!!), but product managers will absolutely bloat your site. "Add this third tracking/analytics tool"; "Add this custom ad format here"; "Oh this partner will give us tons of money if we put this widget on the page"; "Oh let's use Brightcove video player"; "Oh let's auto-play videos"; "drive-by A/B testing"; "We don't control this third-party 2MB image", "The widget streams a 23MB .WAV file for background music that only auto-plays in mobile"; "Why build this in-house when we can just use this good third-party library?"; "Good third-party library costs too much, let's use this horrible but much cheaper one instead"; etc. AMP allows you to tell your product manager: "Sorry! Not supported." Of course, with enough responses like this, a decision eventually comes down to not use AMP.

tmoorai 11y ago
OMG, what kind of product managers do you know. A good one would never ask for such things...
- frandroid 11y ago
  The problem is that I don't work for a tech company, and the product managers have their own silly non-product managers. :) X(
tripzilch 11y ago
> AMP allows you to tell your product manager: "Sorry! Not supported." I like this reason. It's both a good reason for AMP to exist (albeit to solve a sad problem, with the product managers), as well as to justify not using it myself :-) > Of course, with enough responses like this, a decision eventually comes down to not use AMP. Perhaps. But having an external set of guidelines that relate to an all-or-nothing benefit (inclusion in Google's AMP program) seems helpful to me (from the eye of a developer who cares about bloat). A small team of good developers could also formulate their own set of guidelines in order to avoid bloat and achieve fast loading. But those guidelines will have to be guarded by the developers against "political" forces, and there's a distinct possibility that more and more compromises will be made. Exclusion from the AMP program provides a line in the sand, so to say.

wffurr 11y ago

You are correct, but beg the question: why are so many popular websites so slow even if they are essentially static content? If putting a brand on a set of techniques plus offering CDN space and serp priority gets publishers to actually build fast websites, then I am all in favor of it.

tripzilch 11y ago
One reason (but not the whole reason) is that trackers are always essentially dynamic content.

mseebach 11y ago

> I've never understood the use of AMP, just build your normal site properly in the first place and then you won't need it. It's almost like training-wheels for learning efficiency/optimization. I've never understood why toddlers need training wheels on their bikes? Why don't they just bike properly in the first place?

kup0 11y ago
If your view is that web developers working for publishers are "toddlers" in their industry, then I suppose this comparison is apt. I guess the only oversight I see in my original post is that most of the time, the webdevs aren't the ones with the final say anyway and maybe branding the restrictions will make it more palatable to publishers. It's just sad that we're at the point where it has to be done this way. But it is telling that publishers are fine with being restricted by AMP, when they could have implemented those restrictions extremely easily on their own instead of having to be hand-held through the whole thing. The other issue I have is that it's generally intended for mobile only. If the site was built for speed and efficiency from the ground up, it would be a fast experience everywhere

ageitgey 11y ago

"All AMP is, is a decided-upon set of restrictions for what you can do on a page". You say that like it's a bad thing! But that's the entire point. Without a clear set of rules, almost no one makes fast pages in real life. This is especially true when you are working in a company where a wide mix of people have competing objectives. The developers want a fast page, the designers want a pretty page, the PMs want conversion, the business folks want lots of ads, etc. It makes it nearly impossible to build something fast without clear rules. Take a random article on the TheVerge.com as an example. I'm sure they have fantastic web developers who want the site to load quickly and they definitely know how to build beautiful pages. But check out their normal responsive page you get if you visit their site directly on your phone: http://www.theverge.com/2016/3/15/11233030/jj-abrams-moon-shot-review-google-lunar-x-prize-documentary http://www.theverge.com/2016/3/15/11233030/jj-abrams-moon-sh... Using Chrome's "Regular 2G" throttling, that page takes 19.82s to hit DOMContentLoaded and an insane 1.3 minutes to hit Load. The total mobile page weighs 2.5mb! Now check the AMP version of that same page. You can find it by looking for the 'link rel="amphtml"' tag in the header of the page: http://www.theverge.com/platform/amp/2016/3/15/11233030/jj-abrams-moon-shot-review-google-lunar-x-prize-documentary http://www.theverge.com/platform/amp/2016/3/15/11233030/jj-a... Using the same Chrome throttling settings, it hits DOMContentLoaded in 802ms and Load in 33.33s. And even then, almost all of that time is spent loading fonts and (in this particular article, very poorly optimized) images. To a mobile user, that is a way better experience - the difference between bouncing and reading. And the only difference was having "a decided-upon set of restrictions".

kup0 11y ago
As a desktop user, that is a way better experience too, but because AMP seems to be mostly mobile-focused, we desktop users get the "normal" experience typically. If the site was built from the beginning with performance in mind, we'd all benefit, no matter what we're using to view the site. I get that it has more to do with business side of things vs. the development side of things. Lots of hands in the pot at these companies and webdevs are only one part of it.