3 ms·

Google's AMP project was Google's weapon against Facebook's instant news or whatever it was called. It had nothing to do with a quest for better performance. I

Google's AMP project was Google's weapon against Facebook's instant news or whatever it was called. It had nothing to do with a quest for better performance. It had everything to do with ad impressions.

1vuio0pswjnm7 4y ago
As it happens, AMP pages look great in the text-only browser I use and are also an easy solution to many "paywalls". (The text-only browser does not autoload resources, run JS or process CSS.) Even without a browser, it is easy to request AMP pages using a command line utility, extract strings enclosed with "<p></p>" and produce an even smaller, readable web page with no ads.
KronisLV 4y ago
> It had nothing to do with a quest for better performance. It had everything to do with ad impressions. Why not both? Even if the former was the "public justification", AMP pages still performed better than bloatware-ridden websites that otherwise took 2-10 MB to load, not even mentioning the amounts of JS and the impact of it on performance, especially on mobile devices (as well as batter usage on those).
- dmitriid 4y ago
  > not even mentioning the amounts of JS and the impact of it on performance The only reason it performed better is because Google would preload over 1MB of Javascript needed to run AMP on its search page. A cold start for AMP was barely better than most of the top sites that used it. It was cheating, pure and simple. Edit: IIRC it was also preloading the entirety of the search carousel, too. And you could get into the carousel only if you had an AMP page.
  - KronisLV 4y ago
    > The only reason it performed better is because Google would preload over 1MB of Javascript needed to run AMP on its search page. I wonder what he actual metrics are for how often that was used, what % of people chose one of the AMP results, because those were at the top of the list. That preloaded data might be common for most of AMP pages, which is much better than the mess of each site having different React/Angular/Vue bundle versions or even jQuery versions back in the day. As a thought experiment, I wonder how much we could save on bandwidth, if all of the "popular" frameworks/libraries split their base code from each individual application's code (we already have code bundling, after all) and browsers included all of those packages of base code, preloaded. Maybe even follow SEMVER as close as possible, so the browser can always ship the latest minor/patch release for a given major release, to cut down on space needed in the browser. Something along the lines of: <script src="/browser/react@18"></script> <script src="/js/my-app-react-bundle.js"></script> Whereas another app that needs an older version could use: <script src="/browser/react@17"></script> <script src="/js/my-older-react-bundle.js"></script> And if you don't want to participate in such an initiative (or really want a custom version), you could always make sure that your web server serves the "/browser" directory itself. After all, browser install sizes are already horribly bloated, a few dozen MB will hardly matter at this point, whereas each site needing 1-5 MB of JS is absurd, especially because those are re-downloaded for each of them, despite the fact that most sites out there use one of like 3-5 popular solutions.

1vuio0pswjnm7 4y ago

As it happens, AMP pages look great in the text-only browser I use and are also an easy solution to many "paywalls". (The text-only browser does not autoload resources, run JS or process CSS.) Even without a browser, it is easy to request AMP pages using a command line utility, extract strings enclosed with "<p></p>" and produce an even smaller, readable web page with no ads.

KronisLV 4y ago

> It had nothing to do with a quest for better performance. It had everything to do with ad impressions. Why not both? Even if the former was the "public justification", AMP pages still performed better than bloatware-ridden websites that otherwise took 2-10 MB to load, not even mentioning the amounts of JS and the impact of it on performance, especially on mobile devices (as well as batter usage on those).

dmitriid 4y ago
> not even mentioning the amounts of JS and the impact of it on performance The only reason it performed better is because Google would preload over 1MB of Javascript needed to run AMP on its search page. A cold start for AMP was barely better than most of the top sites that used it. It was cheating, pure and simple. Edit: IIRC it was also preloading the entirety of the search carousel, too. And you could get into the carousel only if you had an AMP page.
- KronisLV 4y ago
  > The only reason it performed better is because Google would preload over 1MB of Javascript needed to run AMP on its search page. I wonder what he actual metrics are for how often that was used, what % of people chose one of the AMP results, because those were at the top of the list. That preloaded data might be common for most of AMP pages, which is much better than the mess of each site having different React/Angular/Vue bundle versions or even jQuery versions back in the day. As a thought experiment, I wonder how much we could save on bandwidth, if all of the "popular" frameworks/libraries split their base code from each individual application's code (we already have code bundling, after all) and browsers included all of those packages of base code, preloaded. Maybe even follow SEMVER as close as possible, so the browser can always ship the latest minor/patch release for a given major release, to cut down on space needed in the browser. Something along the lines of: <script src="/browser/react@18"></script> <script src="/js/my-app-react-bundle.js"></script> Whereas another app that needs an older version could use: <script src="/browser/react@17"></script> <script src="/js/my-older-react-bundle.js"></script> And if you don't want to participate in such an initiative (or really want a custom version), you could always make sure that your web server serves the "/browser" directory itself. After all, browser install sizes are already horribly bloated, a few dozen MB will hardly matter at this point, whereas each site needing 1-5 MB of JS is absurd, especially because those are re-downloaded for each of them, despite the fact that most sites out there use one of like 3-5 popular solutions.